Page MenuHomeFreeBSD

virtio_net: Use bus_dma for rxq/txq buffers
Needs ReviewPublic

Authored by sarah.walker2_arm.com on Tue, Feb 24, 4:29 PM.
Tags
None
Referenced Files
F146194180: D55492.id172610.diff
Sat, Feb 28, 3:34 PM
F146155453: D55492.id172871.diff
Sat, Feb 28, 7:22 AM
Unknown Object (File)
Fri, Feb 27, 2:57 AM
Unknown Object (File)
Fri, Feb 27, 2:39 AM
Unknown Object (File)
Fri, Feb 27, 1:39 AM
Unknown Object (File)
Wed, Feb 25, 10:23 PM
Unknown Object (File)
Wed, Feb 25, 9:15 PM
Unknown Object (File)
Wed, Feb 25, 2:37 PM
Subscribers

Details

Reviewers
bryanv
andrew
Summary

While the majority of virtio platforms will be fully coherent, some may
require cache maintenance or other specific device memory handling (eg for
secure partitioning). Using bus_dma allows for these usecases.

The virtio buffers are marked as coherent; this should ensure that sync
calls are no-ops in the common cases.

Sponsored by: Arm Ltd

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 70961
Build 67844: arc lint + arc unit

Event Timeline

A quick test on RISC-V IOMMU gives me this issue:

vtnet0: unable to set MAC address
vtnet0: cannot disable promiscuous mode
vtnet0: cannot disable all-multicast mode
vtnet0: error setting host MAC filter table
panic: alignment failed: ctx 0xffffffd0010d0e80 start 0x20c000 offset 82 align 0x4
In D55492#1270046, @br wrote:

A quick test on RISC-V IOMMU gives me this issue:

vtnet0: unable to set MAC address
vtnet0: cannot disable promiscuous mode
vtnet0: cannot disable all-multicast mode
vtnet0: error setting host MAC filter table
panic: alignment failed: ctx 0xffffffd0010d0e80 start 0x20c000 offset 82 align 0x4

Was there a backtrace?

vtnet0: unable to set MAC address
vtnet0: cannot disable promiscuous mode
vtnet0: cannot disable all-multicast mode
vtnet0: error setting host MAC filter table
panic: alignment failed: ctx 0xffffffd0010d0e80 start 0x20c000 offset 82 align 0x4
cpuid = 0
time = 1772019624
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_fetch_ksymtab() at db_fetch_ksymtab+0x142
kdb_backtrace() at kdb_backtrace+0x2c
vpanic() at vpanic+0x16e
panic() at panic+0x26
iommu_domain_fini() at iommu_domain_fini+0x36a
iommu_is_buswide_ctx() at iommu_is_buswide_ctx+0x806
bus_dmamap_load_mbuf_sg() at bus_dmamap_load_mbuf_sg+0x60
vtmmio_attach() at vtmmio_attach+0x488c
vtmmio_attach() at vtmmio_attach+0x6656
vtmmio_attach() at vtmmio_attach+0x5652
ether_ioctl() at ether_ioctl+0x1a0
vtmmio_attach() at vtmmio_attach+0x5844
in_control_ioctl() at in_control_ioctl+0x9ac
rtnl_ifaces_destroy() at rtnl_ifaces_destroy+0x1a1e
rtnl_register_messages() at rtnl_register_messages+0x2a0
nl_send() at nl_send+0x3ca
nl_taskqueue_handler() at nl_taskqueue_handler+0x34e
taskqueue_run() at taskqueue_run+0x1f0
taskqueue_thread_loop() at taskqueue_thread_loop+0xd4
fork_exit() at fork_exit+0x68
fork_trampoline() at fork_trampoline+0xa
KDB: enter: panic
[ thread pid 0 tid 100062 ]
Stopped at      kdb_enter+0x3a: sd      zero,560(s1)

Should the alignment for the rx & tx DMA tags be VTNET_ETHER_ALIGN?

note function names in backtrace sometimes wrong, so it is more like

bus_dmamap_load_mbuf_sg() -> iommu_bus_dmamap_load_buffer() -> iommu_bus_dmamap_load_something() -> iommu_bus_dmamap_load_something1() -> panic

Should the alignment for the rx & tx DMA tags be VTNET_ETHER_ALIGN?

works with that. There are some warnings, but ping works

vtnet0: unable to set MAC address
vtnet0: cannot disable promiscuous mode
vtnet0: cannot disable all-multicast mode
vtnet0: error setting host MAC filter table
vtnet0: link state changed to UP
vtnet0: error setting host MAC filter table
Starting Network: lo0 vtnet0.
In D55492#1270066, @br wrote:

Should the alignment for the rx & tx DMA tags be VTNET_ETHER_ALIGN?

works with that. There are some warnings, but ping works

vtnet0: unable to set MAC address
vtnet0: cannot disable promiscuous mode
vtnet0: cannot disable all-multicast mode
vtnet0: error setting host MAC filter table
vtnet0: link state changed to UP
vtnet0: error setting host MAC filter table
Starting Network: lo0 vtnet0.

Do the warnings show without this change?

In D55492#1270046, @br wrote:

A quick test on RISC-V IOMMU gives me this issue:

vtnet0: unable to set MAC address
vtnet0: cannot disable promiscuous mode
vtnet0: cannot disable all-multicast mode
vtnet0: error setting host MAC filter table
panic: alignment failed: ctx 0xffffffd0010d0e80 start 0x20c000 offset 82 align 0x4

Could you try again with the most recent change please?

Could you try again with the most recent change please?

same panic

In D55492#1270135, @br wrote:

Could you try again with the most recent change please?

same panic

Apologies, not sure what I was thinking with the previous change. Can you try the current change please?

In D55492#1270135, @br wrote:

Could you try again with the most recent change please?

same panic

Apologies, not sure what I was thinking with the previous change. Can you try the current change please?

It works but shows this warnings. Also vtnet does not seem to work in iommu bypass mode (hangs after "lo0: link state changed to UP").
Could be riscv iommu issue. I'll check on my side. vtblk works fine in all cases

lo0: link state changed to UP
vtnet0: unable to set MAC address
vtnet0: cannot disable promiscuous mode
vtnet0: cannot disable all-multicast mode
vtnet0: error setting host MAC filter table
vtnet0: link state changed to UP
vtnet0: error setting host MAC filter table
Starting Network: lo0 vtnet0.

looks like some part of vtnet still tries to pass physical addresses instead of bus dma addresses, so I get page faults

riscv_fq_intr
riscv_iommu0: Fault: event 0xd received: Read page fault
riscv_iommu0: iotval 0x80e4940a iotval2: 0x0
riscv_iommu0: Fault: event 0xd received: Read page fault
riscv_iommu0: iotval 0x80e4940a iotval2: 0x0
riscv_iommu0: Fault: event 0xd received: Read page fault
riscv_iommu0: iotval 0x80e4940d iotval2: 0x0
riscv_iommu0: Fault: event 0xd received: Read page fault
riscv_iommu0: iotval 0x80e4940d iotval2: 0x0
riscv_iommu0: Fault: event 0xf received: Write/AMO page fault
riscv_iommu0: iotval 0x80e4940f iotval2: 0x0
riscv_iommu0: Fault: event 0xf received: Write/AMO page fault
riscv_iommu0: iotval 0x80e4940f iotval2: 0x0
vtnet0: cannot disable all-multicast mode
In D55492#1270272, @br wrote:

looks like some part of vtnet still tries to pass physical addresses instead of bus dma addresses, so I get page faults

riscv_fq_intr
riscv_iommu0: Fault: event 0xd received: Read page fault
riscv_iommu0: iotval 0x80e4940a iotval2: 0x0
riscv_iommu0: Fault: event 0xd received: Read page fault
riscv_iommu0: iotval 0x80e4940a iotval2: 0x0
riscv_iommu0: Fault: event 0xd received: Read page fault
riscv_iommu0: iotval 0x80e4940d iotval2: 0x0
riscv_iommu0: Fault: event 0xd received: Read page fault
riscv_iommu0: iotval 0x80e4940d iotval2: 0x0
riscv_iommu0: Fault: event 0xf received: Write/AMO page fault
riscv_iommu0: iotval 0x80e4940f iotval2: 0x0
riscv_iommu0: Fault: event 0xf received: Write/AMO page fault
riscv_iommu0: iotval 0x80e4940f iotval2: 0x0
vtnet0: cannot disable all-multicast mode

I'm getting a little confused now. Does vtnet work on RISC-V IOMMU without my changes?

I'm getting a little confused now. Does vtnet work on RISC-V IOMMU without my changes?

Yes, it did work in Bypass mode, and works with this patch as well in bypass.
With translation enabled it does not work before or after the patch, because some part of vtnet still passes physical addresses to HW (instead of busdma addresses).
Since you are converting vtnet to busdma, you could at least identify vtnet operations that are not yet converted.
This would benefit both RISC-V IOMMU and ARM System MMU as they work the same way.

also please keep lines 80 characters long per style(9) as some don't fit my terminal :)

In D55492#1271245, @br wrote:

I'm getting a little confused now. Does vtnet work on RISC-V IOMMU without my changes?

Yes, it did work in Bypass mode, and works with this patch as well in bypass.
With translation enabled it does not work before or after the patch, because some part of vtnet still passes physical addresses to HW (instead of busdma addresses).
Since you are converting vtnet to busdma, you could at least identify vtnet operations that are not yet converted.
This would benefit both RISC-V IOMMU and ARM System MMU as they work the same way.

also please keep lines 80 characters long per style(9) as some don't fit my terminal :)

Could you try https://reviews.freebsd.org/D55564 (in addition to this change set) please?

Could you try https://reviews.freebsd.org/D55564 (in addition to this change set) please?

thanks, it works! Only small issue with large tag alignment