[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi, Keir
Thanks for the detailed explanation.
Regards,
Criping
-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
Sent: 2008年7月29日 18:26
To: Ke, Liping; Jean Guyader; Trolle Selander; Xu, Jiajun
Cc: xen-devel; Ian Jackson
Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up

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@xxxxxxxxx> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.