>-----Original Message-----
>From: Daniel P. Berrangé <[email protected]>
>Subject: Re: [PATCH] intel_iommu: Remove 'x-' prefix from 'x-scalable-mode' and
>'x-flts' properties
>
>On Mon, Mar 09, 2026 at 01:44:15PM +0100, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> On 9/3/26 10:20, Zhenzhong Duan wrote:
>> > We had 'x-scalable-mode' for more than 5 years and 'x-flts' for more than 1
>> > year, it's fine to remove 'x-' now.
>> >
>> > This is a prerequisite to enable intel_iommu's scalable mode and first 
>> > stage
>> > translation support in libvirt.
>> >
>> > Signed-off-by: Zhenzhong Duan <[email protected]>
>> > ---
>> >   docs/devel/vfio-iommufd.rst    | 10 +++++-----
>> >   hw/i386/intel_iommu.c          |  8 ++++----
>> >   hw/i386/intel_iommu_accel.c    |  4 ++--
>> >   tests/qtest/intel-iommu-test.c |  2 +-
>> >   4 files changed, 12 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/docs/devel/vfio-iommufd.rst b/docs/devel/vfio-iommufd.rst
>> > index 78bcdffac7..5755532443 100644
>> > --- a/docs/devel/vfio-iommufd.rst
>> > +++ b/docs/devel/vfio-iommufd.rst
>> > @@ -153,22 +153,22 @@ RAM discarding for mdev.
>> >   ``vfio-ap`` and ``vfio-ccw`` devices don't have same issue as their 
>> > backend
>> >   devices are always mdev and RAM discarding is force enabled.
>> > -Usage with intel_iommu featuring x-flts=on
>> > +Usage with intel_iommu featuring flts=on
>> >   ------------------------------------------
>> >   Only IOMMUFD backed VFIO device is supported when intel_iommu is
>configured
>> > -with x-flts=on, for legacy container backed VFIO device, below error 
>> > shows:
>> > +with flts=on, for legacy container backed VFIO device, below error shows:
>> >   .. code-block:: none
>> > -    qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0: vfio
>0000:02:00.0: Failed to set vIOMMU: Need IOMMUFD backend when x-flts=on
>> > +    qemu-system-x86_64: -device vfio-pci,host=0000:02:00.0: vfio
>0000:02:00.0: Failed to set vIOMMU: Need IOMMUFD backend when flts=on
>> >   VFIO device under PCI bridge is unsupported, use PCIE bridge if 
>> > necessary,
>> >   otherwise below error shows:
>> >   .. code-block:: none
>> > -    qemu-system-x86_64: -device vfio-
>pci,host=0000:02:00.0,bus=bridge1,iommufd=iommufd0: vfio 0000:02:00.0: Failed
>to set vIOMMU: Host device downstream to a PCI bridge is unsupported when x-
>flts=on
>> > +    qemu-system-x86_64: -device vfio-
>pci,host=0000:02:00.0,bus=bridge1,iommufd=iommufd0: vfio 0000:02:00.0: Failed
>to set vIOMMU: Host device downstream to a PCI bridge is unsupported when
>flts=on
>> >   If host IOMMU has ERRATA_772415_SPR17, running guest with
>"intel_iommu=on,sm_off"
>> >   is unsupported, kexec or reboot guest from "intel_iommu=on,sm_on" to
>> > @@ -177,4 +177,4 @@ below if it's not needed by guest:
>> >   .. code-block:: bash
>> > -    -device intel-iommu,x-scalable-mode=off
>> > +    -device intel-iommu,scalable-mode=off
>> > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
>> > index d24ba989bf..001847ad37 100644
>> > --- a/hw/i386/intel_iommu.c
>> > +++ b/hw/i386/intel_iommu.c
>> > @@ -4200,8 +4200,8 @@ static const Property vtd_properties[] = {
>> >       DEFINE_PROP_UINT8("aw-bits", IntelIOMMUState, aw_bits,
>> >                         VTD_HOST_ADDRESS_WIDTH),
>> >       DEFINE_PROP_BOOL("caching-mode", IntelIOMMUState, caching_mode,
>FALSE),
>> > -    DEFINE_PROP_BOOL("x-scalable-mode", IntelIOMMUState,
>scalable_mode, FALSE),
>> > -    DEFINE_PROP_BOOL("x-flts", IntelIOMMUState, fsts, FALSE),
>>
>> IMHO safer would be to officially deprecate these in
>> docs/about/deprecated.rst and keeping them aliased until deprecation
>> period expires. Other changes LGTM.
>
>The purpose of using an 'x-' prefix for properties in QEMU is to declare
>that they are subject to change with no warning, so we are free to change
>them without any deprecation IMHO.

Does that mean I can add another patch to s/flts/fsts opportunistically?
flts(first level translation support) is a naming based on old version vtd spec,
in new spec, it changed to use fsts(first stage translation support) naming.

Thanks
Zhenzhong

Reply via email to