Manuel Bouyer wrote:
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.
Yes, this is supposedly going to be the video region of the guest.
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 ?
Then, when Qemu starts, the guests writes the BAR, and Qemu detects that the guest wants the video ram at address 0xf0000, since this is different from the previous address (0x3f800), Qemu calls xc_domain_add_to_physmap(..., idx=0x3f800, gpfn=0xf0000), thus moving that gfns in the guest p2m.
With current NetBSD implementation, we didn't notice this change, and the NetBSD kernel still thinks this pages in Qemu address space are mapped to 0x3f800, so when Qemu tries to write to this pages in it's address space, NetBSD kernel hits the pagefault and we try to map 0x3f800, getting an error from the hypervisor, because this gfn (0x3f800) is no longer accessible, we should instead try to map the new one (0xf0000).
- 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.
Since this are gfns, they are not "real" addresses, they are just in the p2m guest table handled by the hypervisor. The underlying machine addresses don't change, the only thing that changes are the gfns that Xen assigns to them. So if NetBSD kernel maps the memory directly in the call to xc_map_foreign_bulk, we don't care that the gfns change, since the machine addresses behind those gfn are going to be the same, and we will already have them mapped in Qemu address space correctly.