From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpNjl-0005sX-9h for qemu-devel@nongnu.org; Mon, 23 Jan 2012 12:31:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpNje-000210-Tn for qemu-devel@nongnu.org; Mon, 23 Jan 2012 12:31:21 -0500 Received: from david.siemens.de ([192.35.17.14]:19495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpNje-00020q-I6 for qemu-devel@nongnu.org; Mon, 23 Jan 2012 12:31:14 -0500 Message-ID: <4F1D995A.4020604@siemens.com> Date: Mon, 23 Jan 2012 18:31:06 +0100 From: Jan Kiszka 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> In-Reply-To: <4F1D9649.1000102@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: Avi Kivity , "xen-devel@lists.xensource.com" , Gerd Hoffmann , "qemu-devel@nongnu.org" , Stefano Stabellini On 2012-01-23 18:18, Anthony Liguori wrote: > On 01/23/2012 11:13 AM, Jan Kiszka wrote: >>>>> To reply to your previous question more clearly: at restore time Qemu on >>>>> Xen would run in a non-standard scenario; the restore of the RAM happens >>>>> before QEMU is even started. >>>>> >>>>> That is unfortunate but it would be very hard to change (I can give you >>>>> more details if you are interested in the reasons why it would be so >>>>> difficult). >>>> >>>> If you can't change this, you need to properly introduce this new >>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will >>>> see breakage outside cirrus sooner or later as well. So it might be good >>>> to explain the reason why it can't be changed under Xen when motivating >>>> this concept extension to QEMU. >>> >>> OK. >>> Are you thinking about introducing this concept as a new runstate? >>> This special runstate could be set at restore time only on Xen. >>> >>> >>> BTW the main reasons for having Xen saving the RAM are: >>> >>> - the need to support PV guests, that often run without Qemu; >>> - the current save format, that is built around the fact that Xen saves the memory; >>> - the fact that Qemu might be running in a very limited stub-domain. >> >> Your problem is not the fact that guest RAM is restored by an external >> component. Your problem is that QEMU has no control over the when. If >> you fix this, you could coordinate the restoring with the initial device >> reset and would solve all potential current and future issues, not only >> this single cirrus related one. > > Generally speaking, RAM is an independent device in most useful cases. Onboard > RAM is a very special case because it's extremely unusual. > > But since some video cards can make use of dedicated external RAM, I don't think > any video card really depends on initial RAM state. > > What's most likely here is that the VGA BIOS of a Cirrus card sets an initial > RAM state during device initialization. > > 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. The main problem > here I believe is that we have part of the VGA Bios functionality in the > hardware emulation. 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v4 0/6] save/restore on Xen Date: Mon, 23 Jan 2012 18:31:06 +0100 Message-ID: <4F1D995A.4020604@siemens.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F1D9649.1000102@codemonkey.ws> 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: Anthony Liguori Cc: Avi Kivity , "xen-devel@lists.xensource.com" , Gerd Hoffmann , "qemu-devel@nongnu.org" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 2012-01-23 18:18, Anthony Liguori wrote: > On 01/23/2012 11:13 AM, Jan Kiszka wrote: >>>>> To reply to your previous question more clearly: at restore time Qemu on >>>>> Xen would run in a non-standard scenario; the restore of the RAM happens >>>>> before QEMU is even started. >>>>> >>>>> That is unfortunate but it would be very hard to change (I can give you >>>>> more details if you are interested in the reasons why it would be so >>>>> difficult). >>>> >>>> If you can't change this, you need to properly introduce this new >>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will >>>> see breakage outside cirrus sooner or later as well. So it might be good >>>> to explain the reason why it can't be changed under Xen when motivating >>>> this concept extension to QEMU. >>> >>> OK. >>> Are you thinking about introducing this concept as a new runstate? >>> This special runstate could be set at restore time only on Xen. >>> >>> >>> BTW the main reasons for having Xen saving the RAM are: >>> >>> - the need to support PV guests, that often run without Qemu; >>> - the current save format, that is built around the fact that Xen saves the memory; >>> - the fact that Qemu might be running in a very limited stub-domain. >> >> Your problem is not the fact that guest RAM is restored by an external >> component. Your problem is that QEMU has no control over the when. If >> you fix this, you could coordinate the restoring with the initial device >> reset and would solve all potential current and future issues, not only >> this single cirrus related one. > > Generally speaking, RAM is an independent device in most useful cases. Onboard > RAM is a very special case because it's extremely unusual. > > But since some video cards can make use of dedicated external RAM, I don't think > any video card really depends on initial RAM state. > > What's most likely here is that the VGA BIOS of a Cirrus card sets an initial > RAM state during device initialization. > > 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. The main problem > here I believe is that we have part of the VGA Bios functionality in the > hardware emulation. 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux