On 11/8/23 04:26, Matthew Rosato wrote:
On 11/7/23 1:28 PM, Cédric Le Goater wrote:
On 11/2/23 08:12, Zhenzhong Duan wrote:
Hi,
Thanks all for giving guides and comments on previous series, here is
the v4 of pure iommufd support part.
Based on Cédric's suggestion, this series includes an effort to remove
spapr code from container.c, now all spapr functions are moved to spapr.c
or spapr_pci_vfio.c, but there are still a few trival check on
VFIO_SPAPR_TCE_*_IOMMU which I am not sure if deserved to introduce many
callbacks and duplicate code just to remove them. Some functions are moved
to spapr.c instead of spapr_pci_vfio.c to avoid compile issue because
spapr_pci_vfio.c is arch specific, or else we need to introduce stub
functions to those spapr functions moved.
PATCH 1-5: Move spapr functions to spapr*.c
PATCH 6-20: Abstract out base container
PATCH 21-24: Introduce sparpr container and its specific interface
PATCH 6-24 applied to vfio-next :
https://github.com/legoater/qemu/commits/vfio-next
(with a global s/fucntional/functional/)
I also pushed the remaining patches on :
https://github.com/legoater/qemu/commits/vfio-8.2
with a slight rework of the IOMMUFD configuration, now done per platform.
The VFIO frontend and the 'iommufd' object are only available on x86_64,
arm, s390x.
FYI, I first tried this vfio-8.2 branch on s390x but wasn't actually able to
use the iommufd backend (was getting errors like Property 'vfio-pci.iommufd'
not found) so I think something isn't actually enabling IOMMUFD as expected
with your change...
yes. The previous method used to enable the IOMMUFD device with
a ./configure script option was exposing the CONFIG_IOMMUFD define
globally.
The current method using the Kconfig files requires an extra :
#include CONFIG_DEVICES
in each file using CONFIG_IOMMUFD.
I didn't see it because when compiled natively on x86_64 the
CONFIG_IOMMUFD define is included for some (magic) reason.
It is not the case on other arches, ppc64, aarch64, s390x.
I did the update and repushed vfio-8.2. Should work now.
Instead I tested on s390x using vfio-next + patches 25-41 of this series on top.
Legacy backend regression testing worked fine for vfio-pci, vfio-ap and
vfio-ccw.
ok. Good. This means that vfio-next is in good shape.
Using iommufd backend for vfio-pci on s390 exposes an s390-only issue related
to accounting of vfio DMA limit (code in hw/s390x/s390-pci-vfio.c assumes
VFIODevice.group is never null, but that's no longer true when we use the
iommufd backend with cdev). We don't even need to track this when using the
iommufd backend -- With that issue bypassed, vfio-pci testing on s390x looks
good so far. I'll send a separate fix for that.
Thanks,
C.
Using the iommufd backend for vfio-ccw and vfio-ap did not work, see response
to patch 28.
Thanks,
Matt
