On 2024/8/19 17:41, 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/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.

ok, then let's keep it in this series after refining the commit message a
bit.



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.

I see. yeah, it makes sense.

--
Regards,
Yi Liu

Reply via email to