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: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>
Subject: Re: [Xen-devel] [RFC PATCH 0/3] AMD IOMMU: Share p2m table with iommu
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Mon, 23 May 2011 15:27:18 +0100
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 07:28:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <749B9D3DBF0F054390025D9EAFF47F224C3FD8BA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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> <749B9D3DBF0F054390025D9EAFF47F224C3FD8BA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
At 14:46 +0100 on 23 May (1306162019), Zhang, Yang Z wrote:
> 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?

p2m_types lie between 0 and 14, i.e. four bits.  Cutting from 14 bits to
7 bits still leaves space for another 113 types. 

Tim.

> 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)

-- 
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