WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
From: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>
Date: Mon, 23 May 2011 21:46:59 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Wei Wang <wei.wang2@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Delivery-date: Mon, 23 May 2011 06:47:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110523134055.GG12801@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D8C6F13.6020208@xxxxxxx> <749B9D3DBF0F054390025D9EAFF47F224C328434@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110516082733.GO24068@xxxxxxxxxxxxxxxxxxxxxxx> <749B9D3DBF0F054390025D9EAFF47F224C3288C0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D5301D5BF7D34@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110523105800.GC12801@xxxxxxxxxxxxxxxxxxxxxxx> <749B9D3DBF0F054390025D9EAFF47F224C3FD8B6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110523134055.GG12801@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwZTw+svSu5MI6ZSiqFHlinyjXhFAAAAxAg
Thread-topic: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
No, I mean 0x3fff doesn't mask the low 14 bits but 0x7f only leave the low 7 
bits. How I get the p2m_type which between 8 to 14 bit?

best regards
yang


> -----Original Message-----
> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
> Sent: Monday, May 23, 2011 9:41 PM
> To: Zhang, Yang Z
> Cc: Kay, Allen M; Wei Wang; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with
> iommu
> 
> At 14:33 +0100 on 23 May (1306161213), Zhang, Yang Z wrote:
> > 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?
> 
> The mask is 7F, not 7.
> 
> Tim.
> 
> > 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)
> 
> --
> 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