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