RE: [Xen-ia64-devel] domU stability

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Doesn't a domU virtual address e000010000000009 indicate the 9th entry
in the grant table?  Or am I remembering an old design that wasn't
implemented?  Or if this is correct, where does this translation
get done?  Is it just a normal metaphysical->physical translation in the
3-level lookup table?

Thanks,
Dan

> -----Original Message-----
> From: Matt Chapman [mailto:matthewc@xxxxxxxxxxxxxxx] 
> Sent: Tuesday, November 15, 2005 10:07 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Tian, Kevin; Tristan Gingold; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-ia64-devel] domU stability
> 
> On Tue, Nov 15, 2005 at 06:50:20AM -0800, Magenheimer, Dan 
> (HP Labs Fort Collins) wrote:
> > > >From: Tristan Gingold
> > > >
> > > >I am trying xen-ia64-unstable.hg using changeset 7729.  Dom0 
> > > works well.
> > > >However, domU seems pretty unstable: I got a lot of bad mpa:
> > > >However, I was able to log on domU (after many tries).
> > > >Has any of you the same errors or is it ok ?
> > > 
> > > Hi, Tristan,
> > >   That warning is harmless, and currently the grant table 
> > > pfn is hard code at 0x10000000000 in guest physical, which is 
> > > out of normal guest memory range. When be/fe driver 
> > > communicates, grant table entries are touched and then you 
> > > saw above warnings.
> > 
> > They do not seem to cause any problems but
> > I'm not entirely sure they are harmless.  I think these addresses
> > are domU grant table entries that should be translated to
> > virtual addresses and shouldn't find their way to
> > translate_domain_pte.
> > 
> > Matt, can you comment?
> 
> Yes, as Kevin explains, this is how it's meant to work - the
> grant table is currently mapped into guest physical space at
> that address, above the top of normal guest physical memory.
> 
> Even if the guest kernel access it through a virtual mapping,
> the translation process still goes through translate_domain_pte
> and hence results in that warning (which should be harmless).
> 
> Matt
> 
> 

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel