From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH v4 0/6] save/restore on Xen Date: Mon, 23 Jan 2012 11:07:46 -0600 Message-ID: <4F1D93E2.8050203@codemonkey.ws> References: <4F19AB66.8060901@siemens.com> <4F1D8423.2090603@codemonkey.ws> <4F1D90B7.4060202@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Stefano Stabellini Cc: Jan Kiszka , "xen-devel@lists.xensource.com" , "qemu-devel@nongnu.org" , Avi Kivity List-Id: xen-devel@lists.xenproject.org On 01/23/2012 11:05 AM, Stefano Stabellini wrote: > On Mon, 23 Jan 2012, Anthony Liguori wrote: >>> However the issue of patch #4, "do not reset videoram on resume", still >>> remains: no matter what parameter I pass to Qemu, if qemu_system_reset >>> is called on resume the videoram is going to be overwritten by 0xff. >> >> The memset(0xff) looks dubious to me. My guess is that this could be moved to >> the vgabios-cirrus which would solve your problem. >> >>> In this regard, don't you think it would be advantageous to Qemu in >>> general not to reset the videram in resume? It can be pretty large, so >>> it is a significant waste of a memset. >> >> It claims to fix a real bug. Moving the memset to vgabios would do what you >> want to do in a more robust way I think. > > I think it does fix a bug (Win2K expects RAM to be 0xff at boot, or so a > comment on qemu-xen claims) but certainly it is not supposed to run at > restore time. > I agree that moving the memset to vgabios should be a better way to fix > the problem, I'll give it a look. > Unfortutely it means finding a Win2K install CD to repro the bug, sigh. Right, it's a bit annoying, but a much nicer solution :-) Thanks, Anthony Liguori