andrzej zaborowski writes ("Re: [Qemu-devel] xen / qemu convergence ?"):
> There's currently no way in qemu to map a chunk of host memory to
> guest memory 1:1 if it's not in phys_ram_base, so all video adapters
> in qemu do that. Mapped memory that's part of phys_ram_base also gets
> dirty pages tracking for free. A way to map any arbitrary host address
> to guest RAM would be useful for cases like the vmware-svga where no
> dirty tracking is needed if the SDL framebuffer is made directly
> accessible to guest.
Right. The Xen versions of the vga emulators don't map the vga ram
into the guest's address space wholesale. Accesses to the vga ram all
use the I/O callbacks through the traditional vga memory window. To
improve the performance there's (in as-yet-unreleased versions of Xen)
a Xen-specific shadow memory arrangement which tracks the guest's
writes. (I haven't looked into that in detail.)
(And of course in the Xen case, there is no host memory corresponding
to ordinary guest ram.)
> Cirrus and stdvga code in qemu appears to do exactly the same thing,
> I'm not sure why there is a difference between the two in Xen.
It's just a mistake: the Cirrus emulator had been changed to save its
private memory, but the corresponding required change to stdvga had
been overlooked.
Paul Brook writes ("Re: [Qemu-devel] xen / qemu convergence ?"):
> RAM is RAM. We don't care whether it's nominally owned by the vga controller
> or the "system". If you don't do this then all accesses have to go via
> horribly slow IO callbacks, which is just silly.
I see, yes.
> I've no idea what you're talking about when you say it's "taking up virtual
> address space".
I meant that it allocates part of the space indexed by ram_addr_t but
on rereading the code I think that's not visible to the guest and is
just used for qemu's own bookkeeping so I was mistaken.
Thanks,
Ian.
