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

Today I had a rough try on Guyader's patch, change xen_platform.c
xen_platform_ioport_writeb ->xc_hvm_set_mem_type last param from 0x40 to 0x20. 
Seems not working if I am not wrong.

The patch you mentioned here is the one below?
+        if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x20) || 
xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xf0, 0x10))
             fprintf(logfile,"xen_platform: unable to change ro/rw "
                     "state of ROM memory area!\n");
         else



Regards,
Criping
________________________________________
From: Trolle Selander [mailto:trolle.selander@xxxxxxxxx] 
Sent: 2008å7æ29æ 18:41
To: Keir Fraser
Cc: Ke, Liping; Jean Guyader; Xu, Jiajun; xen-devel; Ian Jackson
Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up

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