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