From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpeHG-0003Ug-Fx for qemu-devel@nongnu.org; Tue, 24 Jan 2012 06:11:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpeHA-0000Me-6n for qemu-devel@nongnu.org; Tue, 24 Jan 2012 06:11:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:4637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpeH9-0000MX-Rq for qemu-devel@nongnu.org; Tue, 24 Jan 2012 06:10:56 -0500 Message-ID: <4F1E91AF.9040402@redhat.com> Date: Tue, 24 Jan 2012 13:10:39 +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> 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: Jan Kiszka , "xen-devel@lists.xensource.com" , Gerd Hoffmann , "qemu-devel@nongnu.org" , Stefano Stabellini On 01/23/2012 07:18 PM, Anthony Liguori wrote: > Generally speaking, RAM is an independent device in most useful cases. Can you give examples? Do you mean a subdevice with composition, or a really independent device? > Onboard RAM is a very special case because it's extremely unusual. What's unusual (or even extremely unusual) about it? I don't see a difference between a few billion bits of state and, say, the few bits of state in an RTC device. > 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. Yes, that's likely. DRAMs aren't reset and some state survives even a short power off. > > 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. Agree. In fact the first step has been taken as now creating a RAM region with memory_region_init_ram() doesn't register it for migration. The next step would be a VMSTATE_RAM() to make it part of the containing device. > 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. Doesn't the main BIOS clear the screen first thing at boot? Not even sure the reset is needed. -- error compiling committee.c: too many arguments to function