On Thu, Oct 26, 2017 at 04:30:57PM +0800, Peter Xu wrote:
> 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.
Right.
> >
> > 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
