Re: [PATCH v2] port/xen: map memory directly in privcmd PRIVCMD_MMAPBATCH

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jun 26, 2012 at 09:43:05AM +0100, Roger Pau Monne wrote:
> Manuel Bouyer wrote:
> >On Mon, Jun 25, 2012 at 09:20:39PM +0100, Roger Pau Monné wrote:
> >>>In this mail, are 0x3f800 and 0xf0000 virtual, physical or machine 
> >>>addresses ?
> >>This are physical address of the guest we are creating.
> >
> >If this is in the guest's address space, how is it affecting the
> >dom0's address space ?
> 
> Qemu is mapping that guest physical address (gfn or gpfn, I'm not
> entirely sure of the terminology) to it's own address space (since
> it's the video ram region of the guest).

OK, so if I understand it properly
- qemu maps pages that will be 0x3f800 in guest's physical space.
  Let says it's mapped at BASE+0x3f800 in qemu's virtual space
  (I assume qemu actually uses a linear mapping of the guest's physical
  space).
- later something (the hypervisor ?) moves this page to 0xf0000 in
  guest's physical space. In which way ? does it remap the underlying mfn
  to a different pfn ?
- In qemu's virtual space the underlying pages are still mapped at
  BASE+0x3f800, when it should now be BASE+0xf0000. How does the
  proposed patch help there ? making the mapping wired won't make
  it move automatically, unless there's some magic happening.


-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--