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