Style.

• explicit panic if the string does not fit static buffer
• reuse isa_extensions static buffer in the legacy routine

Fix checksum offload for IPV6, both receive and transmit paths.

In D59191#1377476, @mmel wrote:

The driver advertises the following: IFCAP_VLAN_MTU, IFCAP_HWCSUM and IFCAP_HWCSUM_IPV6. What happens if the user enables one of these? I only see that IFCAP_RXCSUM is implemented, albeit probably only partially. In all other cases, the driver either emits an invalid packet, is unable to receive a valid packet, or it panics.

resubmit correct file

remove wmb() on receive path as we don't set any descriptor bits prior setting OWN

implement IP checksum offload on receive path

Address @mhorne comments.

remove debug

• add panic() calls in place of TODO comments
• add wmb()

fix hartid type (should be uint32_t)

include the full patch

In D59695#1370984, @mhorne wrote:

Glad to see this moving forward. I only skimmed the overall structure, and in particular I am not confident about MSI code.

My main concern is about this 'pool' mechanism. Why is it important to preallocate these irqsrc structures, and is there any way to be smarter about it (upper bound, or runtime expansion of the pool as-needed?). Unless I am mistaken there is not a high reuse rate.

remove irq pool to simplify operation. Allocate and register IRQs on demand

• don't claim to be root PIC
• switch to intc bus
• NIRQ: lower down the value to 8192
• allocate memory for pcpu_data and imsic_irq_pool

Initialize the child PIC with interrupts disabled on the root PIC

Another idea draft for discussion

In D59813#1372460, @jrtc27 wrote:

Please go read all of D40474

Hi let me improve it a bit first as it looks incomplete

In D59191#1358222, @mmel wrote:

Because both the DMA and the CPU may write to descriptors simultaneously, the driver must require BUS_DMA_COHERENT memory.

Oh, I did not know eqos(4) was imported from NetBSD!

Thanks. We needed that for many years as detaching was sometimes panic system:)

In D56414#1291425, @jrtc27 wrote:

No support for ucontext.h posix API (looks like legacy)

This does need to work; what does Linux do?

Implement ucontext.h POSIX API

In D57405#1315493, @jrtc27 wrote:

Hm, seems the current version is the same as the arm file, and now it's the same as the aarch64 one? I'm guessing copying from arm is how this came to be...

Regenerate

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