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

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

On Sun, 2010-11-14 at 19:08 +0800, Avi Kivity wrote:
> On 11/12/2010 03:16 AM, Huang Ying wrote:
> > 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?
> 
> If d is not too complicated (an ioctl?), we might to it in qemu.

The issue of d) is that there are multiple ways to inject MCE. Now one
software based, one APEI based, and maybe some others in the future.
They all use different interfaces. And as debug interface, there are not
considered kernel ABI too (some are in debugfs). So I think it is better
to use these ABI only in some test suite.

Best Regards,
Huang Ying