Re: [Qemu-devel] host physical address width issues/questions for x86_64

[Peter Xu]

On Mon, Oct 23, 2017 at 10:23:43AM -0700, Prasad Singamsetty wrote:

[...]

> >>Proposal:
> >>
> >>We can simply change the VTD_HOST_ADDRESS_WIDTH to 48 bits
> >>with out any other changes to the code. The current set of
> >>features in the intel iommu emulator code works for q35
> >>machine type and it doesn't have any other side effect.
> >>Since the remapping tables are allocated by the guest kernel
> >>they are always within the phys-bits range and as long
> >>as the same range supported by intel iommu code in QEMU
> >>it works fine. For the current q35 machine type, all the
> >>supported cpus have <= 48 bits as the physical address
> >>width. For short term, just changing the VTD_HOST_ADDRESS_WIDTH
> >>to 48 should work fine for q35. I tried this and it seems
> >>to work fine.
> >
> >I'm fine to change that macro, but IMHO only changing that line may
> >break backward compatibility of old guests (at least it'll change the
> >max address width reported in ACPI).  So I am not sure that's good.
> 
> Could you refer to any specifics on compatibility issues with old
> guests?  The guest linux kernel doesn't seem to report any problem
> with address width in DMAR reported doesn't match with what is
> supported in the host cpu. I would like to better understand the gaps
> we have here.

I mean for example when an old vIOMMU-enabled QEMU migrates to this
new QEMU.  When the guest first probes the DMAR device using the old
QEMU it should have seen 39 bits GAW, but after the migration to your
new QEMU instance it'll become 48 bits.  This can confuse the guest in
some way.  I'm not sure whether that would be a real problem but I
would rather just introduce the new property for 48 bits to avoid that
problem.

> 
> What other machine types intel iommu is supported with the current
> implementation? Is there any test suite that can test intel iommu
> functionality on supported guest types?

I don't think there are lots of tests on VT-d emulation.  There are a
few in kvm-unit-tests for the simplest DMAR and IR tests though, but I
don't think they are checking against compatibility problems.

Thanks,

> 
> >
> >I would prefer still using the new property ("x-aw-bits", or change
> >the name as you prefer) when people really want the 48 bits address
> >width, or even bigger ones in the future.  It makes sure that 39 bits
> >are still the default.
> >
> >CCing Michael who maintains VT-d emulation codes.
> 
> Thanks.
> --Prasad
> 
> >
> >>
> >>For long term, the VTD_HOST_ADDRESS_WIDTH has to match with
> >>host cpu address width. If necessary we may need to define
> >>a new machine type to keep VTD_HOST_ADDRESS_WIDTH value to
> >>match with the host cpu.
> >>
> >>Please let me know if you have any comments or suggestions
> >>on this.
> >
> >Thanks,
> >

-- 
Peter Xu