WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Trolle Selander" <trolle.selander@xxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
From: "Ke, Liping" <liping.ke@xxxxxxxxx>
Date: Tue, 29 Jul 2008 19:22:20 +0800
Cc: "Xu, Jiajun" <jiajun.xu@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Jean Guyader <jean.guyader@xxxxxxxxxxxxx>
Delivery-date: Tue, 29 Jul 2008 04:22:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <515922b50807290340sfa002dbl21d1d2d109dabc8@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C4B4A732.24C18%keir.fraser@xxxxxxxxxxxxx> <C4B4AEDA.24C29%keir.fraser@xxxxxxxxxxxxx> <515922b50807290340sfa002dbl21d1d2d109dabc8@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjxZ4ou8opi4cK0TNyfl5qRnf8/CgABSAJQ
Thread-topic: [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
<Prev in Thread] Current Thread [Next in Thread>