On Sun, May 08, 2022 at 02:19:56PM +0300, Leon Romanovsky wrote: > On Sat, May 07, 2022 at 10:25:16AM +0000, Volodymyr Babchuk wrote: > > Jason Gunthorpe <jgg@xxxxxxxx> writes: > > > On Fri, May 06, 2022 at 03:17:22PM -0500, Bjorn Helgaas wrote: > > > > > >> > Modules linked in: xt_MASQUERADE iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 > > >> > nf_defrag_ipv4 libcrc32c iptable_filter crct10dif_ce nvme nvme_core at24 > > >> > pci_endpoint_test bridge pdrv_genirq ip_tables x_tables ipv6 > > >> > CPU: 3 PID: 287 Comm: sh Not tainted 5.10.41-lorc+ #233 > > >> > Hardware name: XENVM-4.17 (DT) > > > ^^^^^^^^^^^^^^^^^ > > > > > >> So this means the VF must have an SR-IOV capability, which sounds a > > >> little dubious. From PCIe r6.0: > > > > > > Enabling SRIOV from within a VM is "exciting" - I would not be > > > surprised if there was some wonky bugs here. > > > > Well, yes. But in this case, this VM has direct access to the PCIe > > controller. So it should not cause any troubles. I'll try baremetal > > setup, though. > > If I remember correctly, the VM software that runs on hypervisor needs > to filter PCI capabilities even for pass-through devices. > > The vfio kernel module did this for QEMU, so something similar I would > expect from XEN too. AIUI, some kind of translation from GPA to HPA needs to happen, but I'm not sure how that would occur for the VF's enabled within the guest when the host doesn't know about those functions.
