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.