[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH v2] port/xen: map memory directly in privcmd PRIVCMD_MMAPBATCH
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
- 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
Main Index |
Thread Index |