PCIe pass through for Wifi Dev

For the last little while I have been working on porting a WiFi driver. I initially planned to use one of my testbed machines, but the card I had wasn't supported by the original driver and locked up the system.

While waiting for another card I spun up development on the Morefine M6 which had failed complete at its proposed role as a desktop mirrored storage array.

The Morefine M6 has an Intel N200 SoC and supported Intel wifi.

I always set out to try PCIe pass through and the FreeBSD wiki page provided most of what I needed .

On the host you need to exclude the PCIe devices you wish to give to a guest. You need to find the PCIe address for the device to exclude, pciconf -lv is good for this:

# pciconf -lv 
...
none2@pci0:0:20:2:      class=0x050000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x54ef subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'                        
    device     = 'Alder Lake-N PCH Shared SRAM'                 
    class      = memory                                         
    subclass   = RAM                                            
ppt0@pci0:0:20:3:       class=0x028000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x54f0 subvendor=0x8086 subdevice=0x0070
    vendor     = 'Intel Corporation'
    device     = 'CNVi: Wi-Fi'                                  
    class      = network                                        
ig4iic0@pci0:0:21:0:    class=0x0c8000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x54e8 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus                                     
ig4iic1@pci0:0:21:1:    class=0x0c8000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x54e9 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    class      = serial bus 
...

I have passed PCIe device 0:20:3 to my guests, in the pciconf list you will see the driver assigned to the device followed by the bus and the address. So the ig4 i2c driver has devices ig4iic0@pci0:0:21:0 and ig4iic1@pci0:0:21:1 and the 'Wi-Fi' device has been taken by ppt0.

This is configured by adding the PCIe address to /boot/loader.conf :

pptdevs="0/20/3"                # intel wifi

We need to give our PCIe device to our VM, I am simple person and do all my bhyve through vmrun.sh and wrapper shell scripts. For FreeBSD the script is this:

#!/bin/sh                                                                   

diskimage="not set"                                                         
vmname="not set"                                                            
pcidev="0/20/3"                                                             

diskimage="/home/tj/vms/fbsd-iwx.raw"                                       
vmname=$(basename $diskimage .raw)                                          

if [ $# -ge 1 ]                                                             
then                                                                        
        for x in $@                                                         
        do                                                                  
                interfaces="$interfaces -t $x"                              
        done                                                                
else                                                                        
        echo 'usage: launchfreebsd.sh tapDev [tapDev tapDev ...]'           
        exit                                                                
fi                                                                          

echo starting vm $vmname from image $diskimage with interfaces ${interfaces}

sh /usr/share/examples/bhyve/vmrun.sh \                                     
        -c $(nproc) \                                                       
        -m 8G \                                                             
        -p ${pcidev} \                                                      
        ${interfaces} \                                                     
        -d $diskimage \                                                     
        $vmname

And for OpenBSD:

#!/bin/sh                                                                   

diskimage="not set"                                                         
vmname="not set"                                                            
pcidev="0/20/3"                                                             

diskimage="/home/tj/vms/obsd.raw"                                          
vmname=$(basename $diskimage .raw)                                          

#setup="true"                                                               

if [ $# -ge 1 ]                                                             
then                                                                        
        for x in $@                                                         
        do                                                                  
                interfaces="$interfaces -t $x"                              
        done                                                                
else                                                                        
        echo 'usage: $0 tapDev [tapDev tapDev ...]'                         
        exit                                                                
fi                                                                          

echo starting vm $vmname from image $diskimage with interfaces ${interfaces}

if [ -z $setup ]                                                            
then                                                                        
        bhyve -A -D -H -P -S -u -w -c 4 -m 8G                           \   
                -s 0,amd_hostbridge                                     \   
                -s 3,virtio-blk,${diskimage}                            \   
                -s 5,passthru,${pcidev}                                 \   
                -s 10,virtio-net,tap0                                   \   
                -s 20,virtio-rnd                                        \   
                -s 31,lpc -l com1,stdio                                 \   
                -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \   
                $vmname                                                     
else                                                                        

        vmname=openbsd-installer                                            
        echo "Trying to run installer, remember to configure serial"        
        echo "          set tty com0"                                       
        bhyve -A -D -H -P -S -u -w -c 4 -m 8G                           \   
                -s 0,amd_hostbridge                                     \   
                -s 3,virtio-blk,${diskimage}                            \   
                -s 4,ahci-hd,/home/tj/miniroot76.img                    \   
                -s 5,passthru,${pcidev}                                 \   
                -s 10,virtio-net,tap0                                   \   
                -s 20,virtio-rnd                                        \   
                -s 31,lpc -l com1,stdio                                 \   
                -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \   
                $vmname                                                     
fi                                                                          

bhyvectl --destroy --vm=$vmname

In the FreeBSD VM I want to override the default driver so I can test my port this is done by adding a block line to /etc/rc.conf :

devmatch_blocklist="if_iwlwifi"

My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

FreeBSD Network Status Week 48 2024

Goings on

14.2 Release Builds should have started today (or be starting?). If all goes to schedule the release will be out the door and announced on Monday the 3th of December 2024.

BSD Devroom at FOSDEM 2024

The BSD Devroom is back again at FOSDEM this year. The CFP closes on Sunday so this is your last chance to submit something. I hear The FreeBSD Foundation has a stand again this year, so if you want to come and see me in person you could find me there.

Submit early submit often! Now is a bit late, but better than not submitting.

Welcome to the BSD Devroom Call For Participation. The BSD Devroom aims
to provide a dedicated space for presentations covering BSD operating
system family.

Key dates

Proposals can be submitted by October the 30th, 2024
Submission deadline : 1st December 2024 Brussels time
Announcement of selected talks : 15th of December 2024
Conference dates : 1 & 2 February 2025
BSD devroom date : Saturday February 1st, 2025 afternoon (second half)

CFP is here

It was stab week:

On Mon, Nov 25, 2024 at 01:01:05AM -0800, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the November 2024 stabilization week
T> started with FreeBSD/main at main-n273822-ff4c19bb5427, which was tagged as
T> main-stabweek-2024-Nov.

At Netflix testing we didn't discover any new regressions comparing to the
October stabweek.  My personal machines on the new stanpshot are also doing
well.  I didn't receive any emails reporting regressions through the last days,
hence releasing the advisory freeze.

P.S. We are aware of regression in ZFS, that happened between September and
October stabweeks and are working on a reliable reproducer.  A panic happens
when using md(4) device backed by a file on ZFS.

Sounds like there wasn't anything big. This is a reminder that you can directly test your workloads against upcoming releases at a suspected stable point of the tree.

Early testing helps avoid late surprises.

Transport

This is a collision of transport and firewalls ( and I guess packet forwarding). Using the new __tcp_get_flags call teach ppp, pf and ipf about the Accurate ECN AE flag. ECN is one way for the network to communicate with a flow about network conditions.

Small change to memory copying for udp_input , memcpy doesn't need concern itself with overlapping segments and so can be faster.

Network Stack

Fix setting the Don't Fragment bit when tunneling IPv6 over IPv4.

Netdev

Some e1000 changes, the main one here is a further attempt to better implement auto negotiation according to the standard. The commit message has a lot of details and is worth a click through.

More names for T6 cards:

Change the default mode of igc in promisc mode to not show bad packets.

Improvements to mlx5 and family.

Firewalls

Mostly fixes in pf, the first commit here is an improvement to IPv6 fragment handling which just sort of makes me sad. Nothing to do with the change and everything to do with networking.

We have other firewalls too!

User Tooling

With the -n flag the any addr ( 0.0.0.0/0 ) is now printed as default rather than the string default .

Align domain entry so all upper case domains should work. I was expecting this to be a hangover from the past, but RFC 8881 which specifies this behaviour is from 2023. I bet this has confused a lot of people in the past as we are generally pretty loose with capitalization and domain names.

Other stuff

I'm putting this here to highlight it:

Kernel TLS is now enabled by default in kernels including KTLS
support.  KTLS is included in GENERIC kernels for aarch64,
amd64, powerpc64, and powerpc64le.

Please Send Feedback

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

emaste@ would like to know how people are finding these updates. Is it from the mailing list emails, frequent reader of my blog, somewhere else? Please, let me know.

If you find a typo or have a correct let me know and I'll thank you at the end here.

Thanks to:

  • emaste@ for correcting the order of change inthe netstat -n commit.

You can see all prior posts here. ( rss )


My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

FreeBSD Network Status Week 47 2024

A cold snap has hit my part of Europe hard and it is feeling very seasonal. The rate of commits seems down this week, that is probably partially the 14.2 release and if I project a bit the weather.

Some nice changes coming in the WiFi stack and to other tools. In other stuff that I'm not covering here there is some good progress on risc-v support.

Goings on

Fall 2024 FreeBSD Summit

The videos from the Fall FreeBSD summit have been parted out and are available in this playlist:

BSD Devroom at FOSDEM 2024

Welcome to the BSD Devroom Call For Participation. The BSD Devroom aims
to provide a dedicated space for presentations covering BSD operating
system family.

Key dates

Proposals can be submitted by October the 30th, 2024
Submission deadline : 1st December 2024 Brussels time
Announcement of selected talks : 15th of December 2024
Conference dates : 1 & 2 February 2025
BSD devroom date : Saturday February 1st, 2025 afternoon (second half)

CFP is here

FreeBSD 14.2 Code Slush in Effet

THe 14.2 Code Slush is running and final (hopefully changes are landing) RC1 build should have started and we might make it without an RC2 build.

The 14.2-RELEASE cycle schedule as it stands now is:

 ports quarterly branch:  October 1, 2024
 reminder email:          October 7, 2024
 stable/14 slush:         October 18, 2024
 doc/ tree slush:         October 25, 2024
 releng/14.2 branch:      November 1, 2024
 BETA1 build starts:      November 1, 2024
 BETA2 build starts:      November 8, 2024
 doc/ tree tag:           November 8, 2024
 BETA3 build starts:      November 16, 2024
 ports package builds:    November 16-18, 2024
    <<< WE ARE HERE >>>
 RC1 build starts:        November 22, 2024
 RELEASE build starts:    November 29, 2024
 RELEASE announcement:    December 3, 2024
 14.1 EoL:                March 31, 2025
 14.2 EoL:                September 30, 2025
 14.* EoL:                November 30, 2028

https://wiki.freebsd.org/Releng/14.2ISSUES

Transport

I think this is mostly tidying things up, the rename is an adventure in sed. Writing these weekly and sitting on the regular transport calls it is sometimes hard to point at new features. I think the consistent development is a feature.

Network Stack

A nice optimization in forwarding code when we detect a blackholed route.

Netdev

Driver improvements around TSO to support Accurate ECN in the future in igc, em and ixgbe.

Lots of movement in WiFi world. adrian@ has popped back up and started working out a queue of stuff for rtwn. There should be some good improvements to throughput and consistency in HEAD if you want to grab that and try.

We are seeing some steps towards higher rates in rtwn as well.

bz@ landed changes to move iwlwifi from the source tree (and therefore shipped kernel modules) out of the tree. This includes support for adding the needed firmware from the installer, assuming you have internet access in the installer.

Firewalls

Netlink API improvements for pf

Fixes to tests and the build. Lots of tests use the packet accounting in FreeBSD which when we started we quickly learned was missing a lot of packets.

Please Send Feedback

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

If you find a typo or have a correct let me know and I'll thank you at the end here.

You can see all prior posts here. ( rss )

This is the 9th edition of the Weekly Network Status report, currently I plan for the last report of the year to be written on the 13th of December.

I have received a lot of very positive feedback which helps me to write these. Right now I intend to start writing these again in the new year, I might do a summary for the Solstice month all at once, or I'll just do a week. I'm not sure yet.


My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

FreeBSD Network Status Week 46 2024

The meta discussion is moving to the end of the report, meta meta discussion will hopefully be rare.

Goings on

Fall 2024 FreeBSD Summit

The Fall 2024 FreeBSD Summit was last week. There were some great presentations which are recorded on the FreeBSD YouTube Channel . I don't know if or when the sessions will be broken up, you can scroll through the recorded live streams to find talks of interest.

BSD Devroom at FOSDEM 2024

Welcome to the BSD Devroom Call For Participation. The BSD Devroom aims
to provide a dedicated space for presentations covering BSD operating
system family.

Key dates

Proposals can be submitted by October the 30th, 2024
Submission deadline : 1st December 2024 Brussels time
Announcement of selected talks : 15th of December 2024
Conference dates : 1 & 2 February 2025
BSD devroom date : Saturday February 1st, 2025 afternoon (second half)

CFP is here

There are only two weeks left for you to submit something.

FreeBSD 14.2 Code Slush in Effect

From Colin:

This is a reminder that we have one week remaining in the 14.2-RELEASE
code slush and will start BETA builds on November 1st.  The schedule
for the release cycle is:

 ports quarterly branch:  October 1, 2024
 reminder email:          October 7, 2024
 stable/14 slush:         October 18, 2024
 doc/ tree slush:         October 25, 2024
 releng/14.2 branch:      November 1, 2024
 BETA1 build starts:      November 1, 2024
 BETA2 build starts:      November 8, 2024
 doc/ tree tag:           November 8, 2024
    <<< WE ARE HERE >>>
 BETA3 build starts:      November 15, 2024
 ports package builds:    TBD (Between November 8 and 22)
 RC1 build starts:        November 22, 2024
 RELEASE build starts:    November 29, 2024
 RELEASE announcement:    December 3, 2024
 14.1 EoL:                March 31, 2025
 14.2 EoL:                September 30, 2025
 14.* EoL:                November 30, 2028

https://wiki.freebsd.org/Releng/14.2ISSUES

And an update today:

I'm pushing the BETA3 build back by 24 hours so I can re-run this week's
current+stable snapshots; the new container-building code broke stuff but
I *think* I've got it fixed now so I want to try again in case I can get
that into 14.2-BETA3.

This also allows a bit more time for people to look at a vfs issue.  I
already have avg, mckusick, and pho looking at it, but if you know
anything about VFS it would be great to have more eyes; see the thread
"vn_alloc_cyclecount is always zero" and commit ab05a1cf321a.

Note: Colin is only sending these announcements to a private list. I asked him last week if I can share them and he said it wasn't a problem. I'll pester him to share these updates to a public list as well.

Struct ifnet is now hidden

Hi everyone,

Many thanks to everyone involved, either fixing ports, reviewing
changes, or assisting with the API, struct ifnet is now hidden from
drivers and userspace.  This means drivers now use the IfAPI, currently
largely consisting of just getters and setters in place of direct
access, with tools/ifnet/convert_ifapi.sh being a good starting point
for adapting drivers.

In struct ifnet's place is if_t, an opaque pointer.  "Blessed" parts of
the kernel, effectively anything sys/net*, modulo sys/netlink, can
directly access it, as those directories comprise the network stack, so
need direct access, as they manage the interfaces.  Manpage updates
will be coming "soon", I'm hoping in the next few weeks, and will
likely need lots of review and editing.

Again, thanks for everyone's help.  I hope the road forward with this
is not too bumpy.

- Justin

You can find this message on the freebsd-arch mailing list

Removal of devel/kyua

Hi,

Kyua has been part of base since 13.0, today it means all supported versions.

The tests in /usr/tests usually have parity with Kyua in base, i.e. even if we
consider older unsupported systems then new features from the latest port
offer limited benefits. Anyway, these cases are not supported.

So, in order to avoid double work and user confusion, the devel/kyua port is
being considered for removal.

The motivation of this notification is to collect comments and suggestions in
case if the removal is not a good idea for some reasons.


Best regards,
igoro

igoro@ has been doing a lot of work on testing, particularly in pf. This message went to to three mailing lists ( see it on freebsd-hackers )

Transport

rscheff@ is continuing his work on improving SACK behaviour. For the last while we have been discussing TSO behaviour and loss. Other changes are tidy ups to have we do calculations and other macros.

Network Stack

As mentioned above we have a nice series of commits tidying up the use of ifnet to make it private:

Improvements to sendfile in the Linux compat code.

More tidying in the PCB code:

Netdev

It is not often you get a new media type, this comes with a nice explanation:

net: if_media for 1000Base-BX BiDi
1000Base-BX uses two wavelengths, commonly 1310nm, 1490nm, 1550nm, or
1590nm, in a Coarse Wavelength Division Multiplexing (CWDM) arrangement
so that a single fiber strand may carry both upstream and downstream.
It is sometimes referred to as BiDi for bi-directional usage of one
fiber.

Optics must be paired such that the RX and TX wavelengths cross over,
with one side often called U(pstream) and the other D(ownstream).

This technology is useful for increasing link density or working around
construction issues, and is also frequently used as a last mile delivery
technology for FTTx.

And a well known trick for the X520 for lab measurements (no, I don't know this trick).

MAN PAGES!

The only way you get a reputation for good documentation is by continuous consistent improvement.

Some nice changes in WiFi this week, iwlwifi device require firmware which has been in tree until now. It is going to move out of our source tree to somewhere else and be made available by a 'fw update' package of some sort.

Firewalls

Fixes and tidying in pf and more probe points.

If you have used FreeBSD as a developer of a sysadmin you will have heard about how amazing dtrace is. A major quality of life improvement for anyone having to use dtrace for analysis on a live system are discrete probe points. They let you get logical events and make it so you don't have to read kernel code to guess at what is going on (ala fdt probes).

ipfilter is moving forward!

Other stuff

This was an interesting one:

Use the correct idle routine on recent AMD EPYC servers

We have been incorrectly choosing the "hlt" idle method on modern AMD
EPYC servers for C1 idle. This is because AMD also uses the Functional
Fixed Hardware interface. Due to not parsing the table properly for
AMD, and due to a weird quirk where the mwait latency for C1 is
mis-interpreted as the latency for hlt, we wind up choosing hlt for
c1, which has a far higher wake up latency (similar to IO) of roughly
400us on my test system (AMD 7502P).

This patch fixes this by:

- Looking for AMD in addition to Intel in the FFH
 (Note the vendor id of "2" for AMD is not publically documented, but
 AMD has confirmed they are using "2" and has promised to document it.)

- Using mwait on AMD when specified in the table, and when CPUid says
 its supported

- Fixing a weird issue where we copy the contents of cx_ptr for C1 and
 when moving to C2, we do not reinitialize cx_ptr. This leads to
 mwait being selected, and ignoring the specified i/o halt method
 unless we clear mwait before looking at the table for C2.

I'm not sure what the actual impact of this change is, I would guess a reduction in power consumption on most servers (because most servers are at least 40% idle). It might also improve responsiveness, but probably not at a human observable level.

Please Send Feedback

No stream this week, there was a big gap in last nights sleep (hazards of having a young child) and I'm not sure I would make a lot of sense (if I ever do). I have moved the writing time to be around 9am Eastern Time and will aim to stream in this slot next week.

I would love to know if this summary was any help, if it was, or if you think I should cover other thing please let me know (thj@freebsd.org).

If you find a typo or have a correct let me know and I'll thank you at the end here.

You can see all prior posts here. ( rss )


My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the FreeBSD Foundation .

Wireshark 'in' operator

The thing I'm working on has gotten to the point of looking at pcaps. I love a good ol' hexdump (shout out to FreeBSD's in kernel hexdump and honourable mention to printf(9) offering bitfield and byte dump function.

More than a hexdump I love a packet capture. When asked I'll say -xx is my favourite tcpdump flag narrowly beating out -ttttt .

Wireshark expressions can get a bit cumbersome if you are trying to look at many things. Luckily you can use the membership ( in ) operator as a filter . As an example this will give you ieee80211 probe requests, probe responses, assoc requests and responses only requiring you find the types somewhere (like a header file /usr/include/net80211/ieee80211.h ):

#define IEEE80211_FC0_SUBTYPE_MASK              0xf0
#define IEEE80211_FC0_SUBTYPE_SHIFT             4
/* 802.11-2020 Table 9-1-Valid type and subtype combinations */
/* For type 00 Management (IEEE80211_FC0_TYPE_MGT) */
#define IEEE80211_FC0_SUBTYPE_ASSOC_REQ         0x00    /* Association Request */
#define IEEE80211_FC0_SUBTYPE_ASSOC_RESP        0x10    /* Association Response */
#define IEEE80211_FC0_SUBTYPE_REASSOC_REQ       0x20    /* Reassociation Request */
#define IEEE80211_FC0_SUBTYPE_REASSOC_RESP      0x30    /* Reassociation Response */
#define IEEE80211_FC0_SUBTYPE_PROBE_REQ         0x40    /* Probe Request */
#define IEEE80211_FC0_SUBTYPE_PROBE_RESP        0x50    /* Probe Response */
#define IEEE80211_FC0_SUBTYPE_TIMING_ADV        0x60    /* Timing Advertisement */
/* 0111 Reserved                                0x70 */
#define IEEE80211_FC0_SUBTYPE_BEACON            0x80    /* Beacon */
#define IEEE80211_FC0_SUBTYPE_ATIM              0x90    /* ATIM */
#define IEEE80211_FC0_SUBTYPE_DISASSOC          0xa0    /* Disassociation */
#define IEEE80211_FC0_SUBTYPE_AUTH              0xb0    /* Authentication */
#define IEEE80211_FC0_SUBTYPE_DEAUTH            0xc0    /* Deauthentication */
#define IEEE80211_FC0_SUBTYPE_ACTION            0xd0    /* Action */
#define IEEE80211_FC0_SUBTYPE_ACTION_NOACK      0xe0    /* Action No Ack */

The wireshark values are shifted for a 4 bit field already, that gives us a filter like this:

wlan.fc.type_subtype in {0x0000, 0x0001, 0x0004, 0x0005}

If you are trying to figure out a filter in wireshark you can always right click and pick Apply as Filter->Selected .


My work on FreeBSD is supported by the FreeBSD Foundation , you can contribute to improving FreeBSD with code, documentation or financially by donating to the Foundation .