From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH v4 0/6] save/restore on Xen Date: Tue, 24 Jan 2012 07:25:02 -0600 Message-ID: <4F1EB12E.5080802@codemonkey.ws> References: <4F19AB66.8060901@siemens.com> <4F1D4974.4090003@siemens.com> <4F1D4E43.7000501@siemens.com> <4F1D80BA.1040504@siemens.com> <4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws> <4F1D995A.4020604@siemens.com> <4F1D9A8E.1080102@codemonkey.ws> <4F1E8635.2020608@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F1E8635.2020608@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Gerd Hoffmann Cc: "qemu-devel@nongnu.org" , Jan Kiszka , "xen-devel@lists.xensource.com" , Avi Kivity , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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 > >