From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpiac-00018V-LM for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:47:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpiaX-0003hN-DR for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:47:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpiaX-0003h5-5U for qemu-devel@nongnu.org; Tue, 24 Jan 2012 10:47:13 -0500 Message-ID: <4F1ED278.3040707@redhat.com> Date: Tue, 24 Jan 2012 17:47:04 +0200 From: Avi Kivity 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> <4F1EB12E.5080802@codemonkey.ws> In-Reply-To: <4F1EB12E.5080802@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: "qemu-devel@nongnu.org" , Jan Kiszka , "xen-devel@lists.xensource.com" , Gerd Hoffmann , Stefano Stabellini On 01/24/2012 03:25 PM, Anthony Liguori wrote: > >> >>>> 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. It should be done in the way the device spec says it does. What does the qxl spec says? If it's lacking, we need to fill it up from existing practice. > 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. If it's in device firmware, there's no way to tell. Nothing prevents the device from clearing its on-board memory during reset. > > 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 :-)). > You're arguing about changing a device so it could fit qemu better. It should be the other way around. Granted this is a paravirt device so we have more leeway, but still qxl is out there and we can't change it. -- error compiling committee.c: too many arguments to function