At 13:02 +0000 on 08 Dec (1291813359), Wei Wang2 wrote:
> AMD IOMMU supports "skip level" feature, which allows hardware to skip page
> table walks if io address contains long string of 0 bits. To do this, iommu
> page table encodes the level of lower page table directly in bit 9- 11 of
> every pde entry. Therefore, to share p2m table with iommu, either p2m code or
> iommu code has to maintain bit 9- bit 11 in p2m entries as "next level"
> field.
Oh, nice! Thanks for clarifying.
> Also even in leaf entries, amd iommu hardware requires the content of "next
> level" field to be '0' or '7'. So, in order to be more compatible with iommu,
> we should at least use '0' or '7' in bit 9- bit 11 to represent p2m type for
> normal guest ram in the case of PAE.
That's not going to be enough; there are more than two types of memory
that are marked as 'present' in the p2m. I think that we just can't
have IOMMU and p2m sharing a pagetable on PAE builds.
I don't think that having IOMMU support be 64-bit only would be too
terrible, though. A number of other features are 64-bit only, and the
64-bit hypervisor is generally better anyway. Are there going to be
many machines with IOMMUs that don't have 64-bit processors?
Cheers,
Tim.
> > > Also I'm not sure whether the p2m tables ever
> > > get used as host pagetables these days (e.g., when guest has CR0.PG=0).
> > > That could affect how difficult it is to mess with the p2m format.
> >
> > They never get used for PG=0 any more, we have a page in the firmware
> > with a 1-1 4GB mapping instead. But they do get used as pagetables in
> > order to use a linear mapping to read the p2m quickly.
> >
> > > If it's possible, though, it's probably worth pursuing. Sharing the
> > > tables uses less memory, and could be less complicated code too.
> >
> > Yep, sounds like a great idea.
> >
> > Cheers,
> >
> > Tim.
> >
> > > On 07/12/2010 11:20, "Wei Wang2" <wei.wang2@xxxxxxx> wrote:
> > > > Hi Allen,
> > > > Actually, each amd iommu pde entry uses bit 9-11 to encode next page
> > > > table level, but these bits are also used as AVL bits by p2m table to
> > > > encode different page types...So, it might not be quite easy to share
> > > > NPT table with amd iommu unless we change p2m table encoding for this
> > > > first.
> > > > Thanks,
> > > > Wei
> > > >
> > > > On Tuesday 07 December 2010 01:47:22 Kay, Allen M wrote:
> > > >> Hi Wei,
> > > >>
> > > >> My understanding is that both EPT/NPT already supports 2M and 1G page
> > > >> sizes. If this is true and if NPT supports the same page table format
> > > >> as AMD iommu, shouldn't iommu 2M and 1G support just a matter of
> > > >> pointing iommu page table pointer to NPT page table of the same guest
> > > >> OS thus sharing the same page table between NPT and AMD iommu?
> > > >>
> > > >> This should save a lot code changes in iommu code. We just need to
> > > >> flush iommu page table in IOTLB at appropriate places.
> > > >>
> > > >> Allen
> > > >>
> > > >> -----Original Message-----
> > > >> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > >> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Wei Wang2
> > > >> Sent: Friday, December 03, 2010 8:04 AM
> > > >> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> > > >> Subject: [Xen-devel] [PATCH 4/4] amd iommu: Large io page support -
> > > >> implementation
> > > >>
> > > >> This is the implementation.
> > > >>
> > > >> Thanks,
> > > >> We
> > > >> Signed-off-by: Wei Wang <wei.wang2@xxxxxxx>
> > > >> --
> > > >> Legal Information:
> > > >> Advanced Micro Devices GmbH
> > > >> Sitz: Dornach, Gemeinde Aschheim,
> > > >> Landkreis München Registergericht München, HRB Nr. 43632
> > > >> Geschäftsführer:
> > > >> Alberto Bozzo, Andrew Bowd
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > > http://lists.xensource.com/xen-devel
>
>
>
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|