From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpgN7-0003bX-H3 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:25:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpgN1-0004ZX-Je for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:25:13 -0500 Received: from mail-gx0-f173.google.com ([209.85.161.173]:42596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpgN1-0004ZB-H3 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 08:25:07 -0500 Received: by ggnr1 with SMTP id r1so1501314ggn.4 for ; Tue, 24 Jan 2012 05:25:06 -0800 (PST) Message-ID: <4F1EB12E.5080802@codemonkey.ws> Date: Tue, 24 Jan 2012 07:25:02 -0600 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: <4F1E8635.2020608@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 0/6] save/restore on Xen List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: "qemu-devel@nongnu.org" , Jan Kiszka , "xen-devel@lists.xensource.com" , Avi Kivity , Stefano Stabellini 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 > >