WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
From: "Trolle Selander" <trolle.selander@xxxxxxxxx>
Date: Tue, 29 Jul 2008 11:40:33 +0100
Cc: "Xu, Jiajun" <jiajun.xu@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Jean Guyader <jean.guyader@xxxxxxxxxxxxx>, "Ke, Liping" <liping.ke@xxxxxxxxx>
Delivery-date: Tue, 29 Jul 2008 03:41:02 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=L9sqdaoCE3F9fAQ+o2DCnt9pmIXsmsWrnI2Q+O/a/F0=; b=tGFYhEOvbfdPZebMUXnWkOfJs2/otJkH187BOMyalm33ZBVUrhISE3Mm0FS4PcsrnE /IB12emn7oXkkCoYtpn9oAhZ9f/zXx8CVGK/INdP7rCI0ZDop6jaUO2LpsxrkPX54A5g 1tMB3AFXZd5nMzsF+WJDUce+mmSu6g0rzeHeY=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=unnhpoTUUYq71+KA+FUm1axY/ZcF3bSeGZIxyJSDSYQ8KBPbJDov5fSjdo6CzYDfE6 0za+MPjnNgWOGMR/shqoKsWMq48cO4geQp67vpJ3snjG9UXTk1nkIB5U9faSYbuKhyWQ y0886qUfcYZcSaSRAtBM4Iv+XU4+pJY1ja0BM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4B4AEDA.24C29%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C4B4A732.24C18%keir.fraser@xxxxxxxxxxxxx> <C4B4AEDA.24C29%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I don't think there is such a thing as "warm reset" with a Xen HVM - one of the self-modifying functrions at first boot is clobber_entry_point() which overwrites the bios entry with a jump to machine_reset. The patch I posted earlier on this issue should take of the acpi table issue, but maybe we want to tighten the "writable window" to be as narrow as possible?

-- Trolle

2008/7/29 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
I can reproduce the issue. It's two things: firstly certain ACPI tables do
need to be writable (e.g., firmware_waking_vector). Secondly, when the BIOS
re-POSTs it is writing to itself, which we allow on initial boot but not on
warm reset. That needs fixing. I'll take a look at doing so.

 -- Keir

On 29/7/08 10:53, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> Hi,
>
> I didn't actually test cs18120, so I'm not certain that I removed all writes
> to write-protected ROM regions. If such writes are happening then the logging
> at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to the Xen console.
> You may need a debug build of Xen to see them, or add guest_loglvl=all as a
> Xen boot parameter.
>
> The EBDA is simply a RAM area for the BIOS to stash important private (and in
> some cases public) data. Usually it is located just below the VGA framebuffer,
> at around 0x9fc00. Certain parts of it have a well-defined format; other parts
> are completely private to the BIOS. For our purposes all we care about is that
> we do not write-protect it, and we just stash an extra 8-bit variable within
> it to indicate if this is a warm return from S3.
>
>  -- Keir
>
> On 29/7/08 10:47, "Ke, Liping" <liping.ke@intel.com> wrote:
>
>> Hi, Selander and Jean
>>
>> Jiajun is reporting similar (on cs18132) error in latest cs.
>> I found when keeping cs18120, revert 18027, everything is just ok.
>> So cs18120 itself works fine, yet if cs18027 set ro-attributes, problem still
>> exist.
>>
>> Just did some debugging, from ITP, one cpu is in default_idle loop, other one
>> is for-ever running in x86_emulate/memcpy/__hvm_copy, etc. So I think this
>> might be the same problem Guyader meet before?
>>
>> I am not familiar about EBDA, could somebody help me to have a look?
>>
>> Thanks& Regards,
>> Criping
>>
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
>> Sent: 2008年7月24日 20:45
>> To: Jean Guyader; Trolle Selander
>> Cc: xen-devel; Ian Jackson
>> Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
>>
>> On 24/7/08 13:12, "Jean Guyader" <jean.guyader@xxxxxxxxxxxxx> wrote:
>>
>>> Jean Guyader wrote:
>>>> I already tried to reduce the rw area, and just keep 0xe0 -> 0xef. But
>>>> obviously it doesn't work the device model needs to write on this frame
>>>> 0xf1. I still don't figure out why.
>>>
>>> The rombios write on this page because of this flags s3_resume_flag
>>> (rombios.c:98883). I don't know if it's a good reason to set the
>>> rombios as rw. However it's bad to set the first 2 pages of the rombios
>>> as rw just because of that.
>>> Any suggestions ?
>>
>> In that case the changes to ioemu-remote should be reverted. The correct fix
>> is to move the S3 resume flag into the EBDA. I have committed this fix as
>> xen-unstable.hg:18120.
>>
>>  -- Keir
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>