|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen |
Date: | Tue, 24 Jan 2012 07:25:02 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 |
On 01/24/2012 04:21 AM, Gerd Hoffmann wrote:
Hi,We really should view RAM as just another device so I don't like the idea of propagating a global concept of "when RAM is restored" because that treats it specially compared to other devices. But viewing RAM as just another device, having Xen only restore a subset of devices should be a reasonable thing to do moving forward.I don't think modeling device memory (i.e. vga vram) as something independent from the device (vga) is a good idea. Because it isn't.
It is, but probably not in the way you're assuming that I mean it is.
To my understanding, QXL will break identically on Xen for the same reason: the reset handler assumes it can deal with the VRAM as it likes.Yes. Some data structures for host<-> guest communication are living in device memory, and a reset initializes these.
This should be done by firmware or system software. Devices don't initialize memory with data structures on power up. The first problem with doing this is that it assumes a reset order which would lengthen the quiescing process. The second problem is that this would require fairly sophisticated logic that could just as well live in firmware.
The advantage of not enabling a device to behave like this is it lets us do a much simpler reset model. To model this properly, we would have to support multiple reset propagation hooks (at least a preorder and postorder hook). This adds a fair amount of complication for not a lot of benefit (the only benefit is moving firmware logic into QEMU which is really a downside :-)).
Regards, Anthony Liguori
QXL also has a VGA BIOS that it could use to initialize VRAM. A similar change could be made for it.Hmm. Not sure this is a good idea. cheers, Gerd
[Prev in Thread] | Current Thread | [Next in Thread] |