Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address

[Huang Ying <ying.huang@intel.com>]

On Thu, 2010-11-11 at 17:39 +0800, Avi Kivity wrote:
> On 11/11/2010 02:56 AM, Huang Ying wrote:
> > On Thu, 2010-11-11 at 00:49 +0800, Anthony Liguori wrote:
> > >  On 11/10/2010 02:34 AM, Avi Kivity wrote:
> > >  >>  Why the gpa ->   hva mapping is not
> > >  >>  consistent for RAM if -mempath is not used?
> > >  >
> > >  >  Video RAM in the range a0000-bffff and PCI mapped RAM can change gpas
> > >  >  (while remaining in the same hva).
> > >  >
> > >  >  Even for ordinary RAM, which doesn't normally change gpa/hva, I'm not
> > >  >  sure we want to guarantee that it won't.
> > >
> > >  We can't universally either.  Memory hot remove potentially breaks the
> > >  mapping and some non-x86 architectures (like ARM) can alias RAM via a
> > >  guest triggered mechanism.
> >
> > Thanks for clarification. Now I think we have two options.
> >
> > 1) Clearly mark gpa2hva (pfa2hva now, should renamed to gpa2hva) as a
> > testing only interface, and should be used only on restricted
> > environment (normal memory, without hot-remove, maybe only on x86).
> >
> > 2) Find some way to lock the gpa ->  hva mapping during operating. Such
> > as gpa2hva_begin and gpa2hva_end and lock the mapping in between.
> >
> > I think 2) may be possible. But if there are no other users, why do that
> > for a test case? So I think 1) may be the better option.
> >
> 
> 3) Move the poisoning code into qemu, so the command becomes
> 
>     posison-address <addr>
> 
> (though physical addresses aren't stable either)

Poisoning includes:

a) gva -> gpa
b) gpa -> hva
c) hva -> hpa
d) inject the MCE into host via some external tool

poison-address need to do b, c, d. Do you think it is good to do all
these inside qemu?

> 4) Use -mempath on /dev/shm and poison a page in the backing file

If we can poison a page in the backing file, how do we know the
corresponding gpa and hpa?

Best Regards,
Huang Ying