>-----Original Message----- >From: Liu, Yi L <yi.l....@intel.com> >Subject: Re: [PATCH v2 16/17] intel_iommu: Introduce a property to control >FS1GP cap bit setting > >On 2024/8/15 11:46, Duan, Zhenzhong wrote: >> >> >>> -----Original Message----- >>> From: Liu, Yi L <yi.l....@intel.com> >>> Subject: Re: [PATCH v2 16/17] intel_iommu: Introduce a property to >control >>> FS1GP cap bit setting >>> >>> On 2024/8/5 14:27, Zhenzhong Duan wrote: >>>> When host IOMMU doesn't support FS1GP but vIOMMU does, host >>> IOMMU >>>> can't translate stage-1 page table from guest correctly. >>> >>> this series is for emulated devices, so the above statement does not >>> belong to this series. Is there any other reason to have this option? >> >> Good catch, will remove this comment. >> In fact, this patch is mainly for passthrough device where host IOMMU >doesn't support fs1gp. > >I see. To me, as long as the vIOMMU page walk logic supports 1GP large >pages, it's ok to report the FS1GP cap to VM. But it is still fine to >have this property to opt-out FS1GP if admin/orchestration layer(e.g. libvirt) >knows no hw iommu has this capability, so it is better to opt out it >before invoking QEMU. > >Is this your motivation for this property?
Exactly. > >>> >>>> Add a property x-cap-fs1gp for user to turn FS1GP off so that >>>> nested page table on host side works. >>> >>> I guess you would need to sync the FS1GP cap with host before reporting >it >>> in vIOMMU when comes to support passthrough devices. >> >> Yes, we already have this check, see >https://github.com/yiliu1765/qemu/commit/b7ac7ce3a2e21eb1b3172743 >ee6f73e80fe67b3a > >good to know it. :) Will you fail the VM if the device's iommu does not >support FS1GP or just mask out the FS1GP? For cold plugged VFIO device, it will fail the VM with "Stage-1 1GB huge page is unsupported by host IOMMU" error report. For hotplug VFIO device, only hotplug fails with "Stage-1 1GB huge page is unsupported by host IOMMU". We don't update vIOMMU cap/ecap from host cap/ecap per Michael's suggestion, only vIOMMU properties can control them. Thanks Zhenzhong
