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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Ah, S3 is special-cased in machine_reset(). Nice. 

 -- Keir

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

Yes, good point, but yet the POST still happens. :-) I wonder why...

 -- Keir

On 29/7/08 11:40, "Trolle Selander" <trolle.selander@xxxxxxxxx> wrote:

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 <http://liping.ke> @intel.com <http://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

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