On Wednesday 08 December 2010 11:03:18 Tim Deegan wrote:
> Hi,
>
> At 18:00 +0000 on 07 Dec (1291744845), Keir Fraser wrote:
> > Cc'ing Tim -- he could advise how plausible it is to find other available
> > bits to move the p2m types to.
>
> PAE Xen we need to use bits 9-11 because there are no other bits
> available. On 64-bit we could just shift all the type bits up by three;
> I think there's plenty of space above bit 52 for all the types we need.
>
> Even on PAE we really only need to store a p2m type in leaf nodes (l1
> entries and superpage entries) so bits 9-11 are free on internal nodes.
> I don't understand why the iommu tables have a level stored in every
> entry, though - is that a hardware requirement?
Hi Tim,
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.
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.
Thanks,
Wei
>
> > 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home