[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,

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®.