[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and restore vram buffer (revised)



andrzej zaborowski writes ("Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and 
restore vram buffer (revised)"):
> On a second look there's something else I don't understand. The vram
> window is in RAM in stdvga, it's inside phys_ram_base, and the entire
> chunk pointed to by phys_ram_base is saved in vl.c. It's also
> saved/loaded as one of the first things that are loaded so at the time
> stdvga resumes, the vram should already have the correct contents.

(You seem to be talking about the qemu case, rather than the Xen case,
but the principles are the same:)

phys_ram_base is used by qemu to store the guest's ordinary RAM.  It
is accessed by the guest when the guest does memory operations on
physical memory addresses referring to emulated RAM.

However, the emulated stdvga adaptor is not emulated RAM in that
sense.  It registers itself via cpu_register_io_memory, arranging that
references to its memory range of [0xa0000,0xc0000) are diverted to
vga_mem_{read,write}{b,w,l}.  Those functions provide access to the
VGA memory RAM buffer, which on a real video card is a separate set of
RAM chips and in qemu is a separate buffer (s->vram_*).

The access arrangements do not provide direct access to the whole of
the (emulated) VGA RAM.  The VGA RAM is VGA_RAM_SIZE long, ie
generally 8Mby.  That obviously doesn't fit in the available 128Kby of
address space.  Instead, depending on the vga mode a banking
arrangement is used.  See vga_mem_readb, for example.

In any case, vl.c's saving arrangements do save the buffer in
phys_ram_base - but that isn't what the guest sees in the VGA memory
area.  The guest sees the vga memory-mapped IO registers (whose
meaning _is_ generally saved by vga.c), plus it can use the VGA memory
area and those control registers to access the whole of s->vram_ptr in
a bank-switched way.  And it is that whole VGA memory buffer which is
`displayed' to (eg) vlc clients.

The area of phys_ram_base corresponding to the VGA memory area, which
is indeed saved and restored, is not used by anything.  But that's
only 128kby and in any case qemu compresses it.

For guests which make modest use of the vga facilities not saving the
buffer is at most a bit annoying - you just have to ask the guest to
repaint its screen, which is often easy and depending on circumstances
may happen anyway.  But guests which make fuller use of vga (for a
typical example, consider a graphical OS installer or bootloader) that
workaround isn't effective.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.