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>
Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
From: Jean Guyader <jean.guyader@xxxxxxxxxxxxx>
Date: Thu, 31 Jul 2008 11:28:41 +0100
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Xu, Jiajun" <jiajun.xu@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Thu, 31 Jul 2008 03:29:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <391BF3CDD2DC0848B40ACB72FA97AD5903C6FCFF@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>
References: <391BF3CDD2DC0848B40ACB72FA97AD5903C6F647@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C4B61789.24D2F%keir.fraser@xxxxxxxxxxxxx> <391BF3CDD2DC0848B40ACB72FA97AD5903C6FCFF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
Hi,

I give a try yesterday with the latest xen and qemu-remote and
now it also works for me.

Regards,

Ke, Liping wrote:
> Hi, Keir and jiajun
> 
> We found here the reason of triple fault is because eax = 0@point when do 
> "call eax". 
> 
> Strange is that after pull latest tree xen/18178, kernel/622 do a clean 
> build, virtual s3/resume back successfully. I can't reproduce the error 
> anymore. (I use default remote-qemu). I tested both with vtd on and off. Both 
> fine.
> 
> Also dump guest area from 0xfcb00 (upcall jump table area), seems just fine. 
> Now I can't reproduce, I will keep on eye on the problem to see whether it 
> happens again -:(.
> 
> Regards,
> Criping
> 
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
> Sent: 2008年7月30日 20:05
> To: Ke, Liping; Tian, Kevin; Xu, Jiajun; Yu, Ke; Jiang, Yunhong
> Cc: xen-devel; Ian Jackson
> Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
> 
> No, not necessarily. Obviously some other exception or interrupt has
> occurred here and lack of a valid IDT has turned it into a triple fault. It
> oughtn't to be an interrupt since your RFLAGS.IF = 0. The fact that
> RFLAGS.RF = 1 is perhaps interesting (could very well not be related to your
> problem though).
> 
>  -- Keir
> 
> On 30/7/08 12:50, "Ke, Liping" <liping.ke@xxxxxxxxx> wrote:
> 
>> Btw: need TR register be set when switching to protect mode?
>> -----Original Message-----
>> From: Ke, Liping 
>> Sent: 2008年7月30日 19:44
>> To: Tian, Kevin; Keir Fraser; Xu, Jiajun; Yu, Ke; Jiang, Yunhong
>> Cc: xen-devel; Ian Jackson
>> Subject: RE: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
>>
>> Hi, all
>> Just found:
>> When doing get_s3_waking_vector(rombios.c)->upcall(32bitgateway.c)->
>> switch_to_protmode-> call eax (I add a deadloop in get_s3_wakeing_vector @
>> beginning, so I think first instruction will fail@call eax) , it will meet
>> triple fault with below information:
>>
>>
>> (XEN) VMEntry: intr_info=00000031 errcode=00000006 ilen=00000000
>> (XEN) VMExit: intr_info=00000000 errcode=00000043 ilen=00000000
>> (XEN)         reason=00000002(trip fault) qualification=00000000
>>
>> Seems mostly caused by protect mode execution environment after switching to
>> protect mode. I dump both normal and abnormal vmcs. Could anybody help to
>> identify below information:
>> 1. Whether gdtr/ldtr selector/base/attr could be 0/0/0x93 in protect mode
>> 2. gs/fs limit should be 0xfffffffff instead of 0xffff in protect mode?
>> 3. cr0 and cr4 bit such as PAE/PSE makes different? I guess No?
>> 4. Guest EFER now should be 0. It is correct when switching to protect mode?
>>
>> Any input is warmly welcome, really not familiar with asm code in 
>> 32bitgateway
>> -:)
>> Thanks a lot!
>> Criping
>>
>> Triple fault point vmcs:
>> (XEN) >>> Domain 1 <<<
>> (XEN)  VCPU 0
>> (XEN) *** Guest State ***
>> (XEN) CR0: actual=0x0000000080010031, shadow=0x0000000000000011,
>> gh_mask=fffffff
>> fffffffff
>> (XEN) CR4: actual=0x0000000000002020, shadow=0x0000000000000000,
>> gh_mask=fffffff
>> fffffffff
>> (XEN) CR3: actual=0x000000007d3eba20, target_count=0
>> (XEN)      target0=0000000000000000, target1=0000000000000000
>> (XEN)      target2=0000000000000000, target3=0000000000000000
>> (XEN) RSP = 0x000000000000ffe8 (0x000000000000ffe8)  RIP = 0x0000000000000003
>> (0
>> x0000000000000003)
>> (XEN) RFLAGS=0x0000000000010082 (0x0000000000010082)  DR7 = 
>> 0x0000000000000400
>> (XEN) Sysenter RSP=00000000c1809300 CS:RIP=0060:00000000c0403f4c
>> (XEN) CS: sel=0x0008, attr=0x00c9b, limit=0xffffffff, base=0x0000000000000000
>> (XEN) DS: sel=0x0018, attr=0x00c93, limit=0xffffffff, base=0x0000000000000000
>> (XEN) SS: sel=0x0018, attr=0x00c93, limit=0xffffffff, base=0x0000000000000000
>> (XEN) ES: sel=0x0018, attr=0x00c93, limit=0xffffffff, base=0x0000000000000000
>> (XEN) FS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
>> (XEN) GS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
>> (XEN) GDTR: sel=0x0000, attr=0x00000, limit=0x0000001f,
>> base=0x00000000000fa5f0
>> (XEN) LDTR: sel=0x0000, attr=0x00082, limit=0x0000ffff,
>> base=0x0000000000000000
>> (XEN) IDTR: sel=0x0000, attr=0x00000, limit=0x0000ffff,
>> base=0x0000000000000000
>> (XEN) TR: sel=0x0000, attr=0x0008b, limit=0x0000ffff, base=0x0000000000000000
>> (XEN) TSC Offset = ffffffc32074372c
>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000
>> (XEN) Interruptibility=0000 ActivityState=0000
>> (XEN) *** Host State ***
>> (XEN) RSP = 0xffff83007d3f7fa0  RIP = 0xffff828c80181200
>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e060
>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c80274c80
>> (XEN) GDTBase=ffff820000000000 IDTBase=ffff83007c69c080
>> (XEN) CR0=0000000080050033 CR3=000000007b59c000 CR4=00000000000026b0
>> (XEN) Sysenter RSP=ffff83007d3f7fd0 CS:RIP=e008:ffff828c801a5290
>> (XEN) *** Control State ***
>> (XEN) PinBased=0000003f CPUBased=b6a1e7fa SecondaryExec=00000041
>> (XEN) EntryControls=000011ff ExitControls=0003efff
>> (XEN) ExceptionBitmap=00044000
>> (XEN) VMEntry: intr_info=00000031 errcode=00000006 ilen=00000000
>> (XEN) VMExit: intr_info=00000000 errcode=00000043 ilen=00000000
>> (XEN)         reason=00000002 qualification=00000000
>> (XEN) IDTVectoring: info=00000000 errcode=00000000
>> (XEN) TPR Threshold = 0x00
>> (XEN) EPT pointer = 0x0000000000000000
>> (XEN) Virtual processor ID = 0x0000
>> (XEN) **************************************
>>
>>
>> Normal vmcs
>> (XEN)  VCPU 0
>> (XEN) *** Guest State ***
>> (XEN) CR0: actual=0x000000008005003b, shadow=0x0000000080050033,
>> gh_mask=fffffff
>> fffffffff
>> (XEN) CR4: actual=0x00000000000026f0, shadow=0x00000000000006f0,
>> gh_mask=fffffff
>> fffffffff
>> (XEN) CR3: actual=0x000000007d3eba20, target_count=0
>> (XEN)      target0=0000000000000000, target1=0000000000000000
>> (XEN)      target2=0000000000000000, target3=0000000000000000
>> (XEN) RSP = 0x00000000f3a7de9c (0x00000000f3a7de9c)  RIP = 0x00000000c0506769
>> (0
>> x00000000c050676b)
>> (XEN) RFLAGS=0x0000000000000046 (0x0000000000000046)  DR7 = 
>> 0x0000000000000400
>> (XEN) Sysenter RSP=00000000c1809300 CS:RIP=0060:00000000c0403f4c
>> (XEN) CS: sel=0x0060, attr=0x00c9b, limit=0xffffffff, base=0x0000000000000000
>> (XEN) DS: sel=0x007b, attr=0x00cf3, limit=0xffffffff, base=0x0000000000000000
>> (XEN) SS: sel=0x0068, attr=0x00c93, limit=0xffffffff, base=0x0000000000000000
>> (XEN) ES: sel=0x007b, attr=0x00cf3, limit=0xffffffff, base=0x0000000000000000
>> (XEN) FS: sel=0x0000, attr=0x00c00, limit=0xffffffff, base=0x0000000000000000
>> (XEN) GS: sel=0x0033, attr=0x00df3, limit=0xffffffff, base=0x00000000b7f058d0
>> (XEN) GDTR: sel=0x0033, attr=0x00000, limit=0x000000ff,
>> base=0x00000000c1810000
>> (XEN) LDTR: sel=0x0088, attr=0x00082, limit=0x00000027,
>> base=0x00000000c078b020
>> (XEN) IDTR: sel=0x0088, attr=0x00000, limit=0x000007ff,
>> base=0x00000000c06e0000
>> (XEN) TR: sel=0x0080, attr=0x0008b, limit=0x00002073, base=0x00000000c1807100
>> (XEN) TSC Offset = ffffffc32074372c
>> (XEN) DebugCtl=0000000000000000 DebugExceptions=0000000000000000
>> (XEN) Interruptibility=0000 ActivityState=0000
>> (XEN) *** Host State ***
>> (XEN) RSP = 0xffff828c8023ffa0  RIP = 0xffff828c80181200
>> (XEN) CS=e008 DS=0000 ES=0000 FS=0000 GS=0000 SS=0000 TR=e040
>> (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff828c80274c00
>> (XEN) GDTBase=ffff820000000000 IDTBase=ffff828c80278500
>> (XEN) CR0=000000008005003b CR3=000000007b59c000 CR4=00000000000026b0
>> (XEN) Sysenter RSP=ffff828c8023ffd0 CS:RIP=e008:ffff828c801a5290
>> (XEN) *** Control State ***
>> (XEN) PinBased=0000003f CPUBased=b6a1e7fa SecondaryExec=00000041
>> (XEN) EntryControls=000011ff ExitControls=0003efff
>> (XEN) ExceptionBitmap=00044080
>> (XEN) VMEntry: intr_info=00000031 errcode=00000006 ilen=00000000
>> (XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000000
>> (XEN)         reason=0000001e qualification=1f440001
>> (XEN) IDTVectoring: info=00000000 errcode=00000000
>> (XEN) TPR Threshold = 0x00
>> (XEN) EPT pointer = 0x0000000000000000
>> (XEN) Virtual processor ID = 0x0000
>> (XEN) **************************************
>>
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ke, Liping
>> Sent: 2008年7月30日 12:49
>> To: Tian, Kevin; Keir Fraser; Xu, Jiajun; Yu, Ke
>> Cc: xen-devel; Ian Jackson
>> Subject: RE: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
>>
>> Hi, Kevin
>> Thanks for the detailed explanation. Now I understand it :)
>> Then most of guests with correct initial value should use legacy wakeup
>> vector. The guests I have tested should be so.
>>
>> Strange thing is that with top of tree, when do resume, it will do reset,
>> mostly caused by not getting wakeup vector. I will dig into the reason.
>>
>> Thanks& Regards,
>> Criping
>>
>> -----Original Message-----
>> From: Tian, Kevin
>> Sent: 2008年7月30日 11:09
>> To: Ke, Liping; Keir Fraser; Xu, Jiajun; Yu, Ke
>> Cc: xen-devel; Ian Jackson
>> Subject: RE: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up
>>
>> Liping, it's not guest BIOS to choose which instead should simply
>> follow ACPI spec, i.e, if OSPM fills value in x_firmware field, then
>> guest BIOS picks that value as wakeup vector in a flat protect mode.
>> Else, if OSPM fills value in legacy firmware field, guest BIOS then
>> resumes to given address in real mode.
>>
>> It's the OSPM to decide which field to be used, according to whether
>> its wakeup vector is developed as real mode code. Then it's not 'us'
>> to decide. :-)
>>
>> Commodity OSes are all using real mode wakeup vector by far. But
>> there's a known bug in Linux kernel where, whether to use x_firmware
>> field is incorrectly counted by its initial value. Normally BIOS will fill
>> zero in that field which avoids Linux to use xfirmware field. If guest
>> BIOS incorrectly puts some value in that field, guest Linux will choose
>> xfirmware field although it only has real mode wakeup vector. But
>> this is a guest bug.
>>
>> Thanks,
>> Kevin
>>
>>
>>> From: Ke, Liping
>>> Sent: 2008年7月30日 10:51
>>>
>>> Hi, Keir
>>>
>>> Sure. I am looking on it:)
>>> Just got someinfo, according to the ACPI spec, when we are
>>> using x_firmware_waking_vector, we should wake up from protect
>>> mode. Since we now resume back from real mode, so we'd better
>>> use firmware_waking_vector.
>>>
>>> Thanks a lot!
>>> Criping
>>>
>>>
>>> -----Original Message-----
>>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>>> Sent: 2008年7月29日 23:12
>>> To: Ke, Liping; Xu, Jiajun
>>> Cc: xen-devel; Ian Jackson
>>> Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3
>>> state wake up
>>>
>>> I fixed these issues as of changeset 18166. However S3 resume
>>> is still not
>>> working for me. Perhaps it's something to do with the new ioemu-remote
>>> repository? Anyway, I'll hand it back to you to dig into further. ;-)
>>>
>>> Oh, also our handling of x_firmware_waking_vector appears not
>>> good. If the
>>> OSPM specifies that vector, are we not supposed to wake it in
>>> flat protected
>>> mode?
>>>
>>> -- Keir
>>>
>>> On 29/7/08 11:26, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>>>
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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


-- 
Jean Guyader

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