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: "Ke, Liping" <liping.ke@xxxxxxxxx>, Trolle Selander <trolle.selander@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 29 Jul 2008 12:50:37 +0100
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:51:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <391BF3CDD2DC0848B40ACB72FA97AD5903C3985A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjxZ4ou8opi4cK0TNyfl5qRnf8/CgABSAJQAAEpqJM=
Thread-topic: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
User-agent: Microsoft-Entourage/11.4.0.080122
Be sure you are building the ioemu you think you are. By default we now
build in directory tools/ioemu-remote, which is a clone of an out-of-tree
git repository.

 -- Keir

On 29/7/08 12:22, "Ke, Liping" <liping.ke@xxxxxxxxx> wrote:

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