Another question? Does this change ok? How to covert the p2m_type whose value
great than 7 to flags, like the type p2m_ram_shared which equal to 13?
diff -r 51d89366c859 -r 78145a98915c xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c Mon Apr 18 15:12:04 2011 +0100
+++ b/xen/arch/x86/mm/p2m.c Mon Apr 18 17:24:21 2011 +0100
@@ -80,7 +80,12 @@
{
unsigned long flags;
#ifdef __x86_64__
- flags = (unsigned long)(t & 0x3fff) << 9;
+ /*
+ * AMD IOMMU: When we share p2m table with iommu, bit 9 - bit 11 will be
+ * used for iommu hardware to encode next io page level. Bit 59 - bit 62
+ * are used for iommu flags, We could not use these bits to store p2m
types.
+ */
+ flags = (unsigned long)(t & 0x7f) << 12;
best regards
yang
> -----Original Message-----
> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
> Sent: Monday, May 23, 2011 6:58 PM
> To: Kay, Allen M
> Cc: Zhang, Yang Z; Wei Wang; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with
> iommu
>
> Hi,
>
> At 01:51 +0100 on 21 May (1305942710), Kay, Allen M wrote:
> > The common code that caused problem is the following.
> >
> > typedef enum {
> > - p2m_invalid = 0, /* Nothing mapped here */
> > - p2m_ram_rw = 1, /* Normal read/write guest RAM */
> > + p2m_ram_rw = 0, /* Normal read/write guest RAM */
> > + p2m_invalid = 1, /* Nothing mapped here */
> >
> > With the above change, guest with device direct assignment fails to
> > boot. QEMU VGA displays some weird color patterns.
>
> Unfortunately this change seems to be necessary for AMD IOMMU to share
> pagetables with the p2m. I'd rather we didn't have it, because it means
> empty ptes look like RAM mappings of frame 0. :(
>
> Wei, is there any way we can reorganise the AMD IOMMU pagetables so we
> can store the p2m type somewhere that's not required to be zero? If not, I'm
> inclined to revert the p2m-sharing for AMD IOMMUs, since at the very least
> we'd like to be able to handle types other than ram_rw (e.g. ram_ro).
>
> In the meantime, Allen, does the attached patch make things any better for
> you?
>
> Cheers,
>
> Tim.
>
> --
> 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
|
Home