qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen


From: Stefano Stabellini
Subject: Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
Date: Tue, 24 Jan 2012 11:52:28 +0000
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

On Tue, 24 Jan 2012, Avi Kivity wrote:
> On 01/24/2012 01:27 PM, Paolo Bonzini wrote:
> > On 01/24/2012 12:10 PM, Avi Kivity wrote:
> >>> But viewing RAM as just another device, having Xen only restore a
> >>> subset of devices should be a reasonable thing to do moving forward.
> >>> The main problem here I believe is that we have part of the VGA Bios
> >>> functionality in the hardware emulation.
> >>
> >> Doesn't the main BIOS clear the screen first thing at boot?  Not even
> >> sure the reset is needed.
> >
> > Clearing the screen should only write to the RAM at 0xB8000 (and
> > perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
> > option ROM cannot even assume that the main BIOS knows about the VESA
> > framebuffer, can it?
> 
> Yes, but why should anything else be needed?
> 
> When you switch to a graphics mode, clear as much of the framebuffer as
> you need.

After installing Win2K, I managed to reproduce the issue with the old
qemu-xen and rombios (removing the memset in the vga emulator).
However I cannot reproduce the issue with upstream qemu and seabios
(even if I remove the memset).

I think that the memset was a workaround a bug in rombios, hence it is
not needed anymore.

Removing the cirrus_vga memset would solve the main issue we have left
with save/restore on Xen.
However it wouldn't solve the problem for QXL: as Gerd pointed out, QXL
needs a reset to initialize some memory regions, so another "if we are
restoring don't do that" would be required to make it work on Xen...

Maybe we can extend the loadvm == 1 to all the reset performed before
load_vmstate?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]