[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4/4] amd iommu: Large io page support - implementation



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.