In D55492#1272968, @adrian wrote:

also - are D55492 and D55564 supposed to be tested together in a stack? which should be applied first?

Apply D55492, then D55564.
Just tested these in qemu: vtnet put behind an IOMMU controller on RISC-V with translation enabled, seem to work fine!

Same toolchain (latest), but without this change a few functions don't have landing pad: copyin/copyout and sched_idletd.

In D55636#1273367, @andrew wrote:

How does it fix the Branch Target exception? The kernel doesn't care about the note, it's just there to ensure all source files are built with BTI enabled.

In D55564#1272503, @sarah.walker2_arm.com wrote:

Change header tag alignment size.

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

found another bug here, will resubmit

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

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#1270142, @sarah.walker2_arm.com wrote:

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?

Could you try again with the most recent change please?

same panic

In D55492#1270064, @andrew wrote:

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

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

if td1 is always curthread, then a kassert is needed

I tested this on RISC-V IOMMU under QEMU ("virt" machine) and modern virtio PCI -- seem to work!

In D55220#1262908, @jrtc27 wrote:

Oh I see, the point is about what's passed up as the second argument, not what device the method is invoked on. I guess then my question becomes why is the DMA tag special? We don't do this for resources, and we don't do this for the bus space tag. Is that just because normally it's virtio_pci doing the resource allocation?

In D55220#1262735, @jrtc27 wrote:

How does this differ from the default implementation specified in sys/kern/bus_if.m, namely bus_generic_get_dma_tag?

how hard it would be to implement MSI interface here? to support MSI interrupts from devices, which is a crucial functionality

remove unused functions/prototypes

Indeed. I do find however that this actually fixes my issue with if_xae when tag alignment requirement for TX/RX buffers is downgraded to lower values.

Agree on using PAGE_SIZE for everyone. Most likely more controllers have this issue (even within Crucial model range), so it is a way easier to align to page_size all of them rather than deal with bug reports from users. We are a general purpose OS.
And again, Linux align to PAGE_SIZE all of them as well.

rename macro

The issue arise on Crucial P310 only, so convert to a quirk

looks redundant. thanks

What I see when 32 byte requested it actually gives us PAGE_SIZE aligned address, which works.

Good points. I will check with Codasip if this is something to do with CHERI (I don't see any connection however)

Thanks @pkelsey. I will look at this once again (I did not forget about this but need to restore my CVA6 setup).

Regenerate

Add hwt.4 to the build and create MLINKS

In D51192#1169501, @ziaee wrote:

https://man-dev.freebsd.org/vt
And in current (not synced to web interface yet), check out uftdi, uchcom, or pf

rework SYNOPSIS

improve HOOKS section

Address @ziaee comments

reorder

Spelling

Fix issues found by mandoc lint