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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

I fixed these issues as of changeset 18166. However S3 resume is still not
working for me. Perhaps it's something to do with the new ioemu-remote
repository? Anyway, I'll hand it back to you to dig into further. ;-)

Oh, also our handling of x_firmware_waking_vector appears not good. If the
OSPM specifies that vector, are we not supposed to wake it in flat protected
mode?

 -- Keir

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

> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel