ioemu-remote: ACPI S3 state wake up

PATCH Applied Jean Guyader 6 participants 29 messages Jul 23, 2008 – Jul 31, 2008

lore

Share & tools

lore

Jean Guyader

author

2008-07-23 17:51 UTC #0 lore raw

PATCH 1/1 ioemu-remote: ACPI S3 state wake up

ioemu-remote: The device model needs to write in the ACPI tables when it wakes up from S3 state.

Signed-off-by Jean Guyader <[email protected]>

Signature · 1 line

Jean Guyader

hw/xen_platform.c +1 -1

index 430e603..06f6edb 100644
@@ -59,7 +59,7 @@ static void xen_platform_ioport_writeb(void *opaque, uint32_t addr, uint32_t val
     case 0: /* Platform flags */ {
         hvmmem_type_t mem_type = (val & PFFLAG_ROM_LOCK) ?
             HVMMEM_ram_ro : HVMMEM_ram_rw;
-        if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x40))
+        if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x20))
             fprintf(logfile,"xen_platform: unable to change ro/rw "
                     "state of ROM memory area!\n");
         else

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ian Jackson

Applied

2008-07-23 18:02 UTC #1 lore raw

Jean Guyader writes ("[PATCH] ioemu-remote: ACPI S3 state wake up"):

Quoted 2 lines

ioemu-remote: The device model needs to write in the ACPI tables when it wakes up from S3 state.

I've applied this but I have to say these magic numbers

hw/xen_platform.c static void xen_platform_ioport_writeb(void *opaque, uint32_t addr, uint32_t val · line 62

Quoted 2 lines

hw/xen_platform.c +1 -1

-        if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x40))
+        if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x20))

are pretty unpleasant! Are they directly derived from addresses specified in ACPI ? I haven't looked ...

Ian.

Don't leave the main rombios unprotected. I also added a comment to explain the "magic numbers", since their meaning is perhaps not as obvious as I thought, in particular now that we're no longer blanket-protecting the entire firmware area anymore.

/ Trolle

Signed-off-by Trolle Selander <[email protected]

<mailto:[email protected]> <[email protected]>

Quoted 10 lines · Ian Jackson

Jean Guyader writes ("[PATCH] ioemu-remote: ACPI S3 state wake up"):
Quoted 2 lines
ioemu-remote: The device model needs to write in the ACPI tables when it wakes up from S3 state.
I've applied this but I have to say these magic numbers
Review
Quoted 2 lines
(quoted diff) +1 -1
-        if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x40))
+        if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x20))
are pretty unpleasant! Are they directly derived from addresses specified in ACPI ? I haven't looked ...

Quoted 7 lines

Ian.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

hw/xen_platform.c +4 -1

diff -uNr a/hw/xen_platform.c b/hw/xen_platform.c
@@ -59,7 +59,10 @@
     case 0: /* Platform flags */ {
         hvmmem_type_t mem_type = (val & PFFLAG_ROM_LOCK) ?
             HVMMEM_ram_ro : HVMMEM_ram_rw;
-        if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x40))
+        /* The numbers passed below are pfns and page counts representing the memory ranges:
+           0xc0000 - 0xdffff - VGABIOS and option ROMS (extboot, ethboot, etc)
+           0xf0000 - 0xfffff - the main ROMBIOS */
+        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

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ian Jackson

2008-07-24 10:35 UTC #3 lore raw

Trolle Selander writes ("Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up"):

Quoted 4 lines

Don't leave the main rombios unprotected. I also added a comment to explain the "magic numbers", since their meaning is perhaps not as obvious as I thought, in particular now that we're no longer blanket-protecting the entire firmware area anymore.

Thanks ...

hw/xen_platform.c line 68

Quoted 9 lines

hw/xen_platform.c +5 -1

-    if (xc_hvm_set_mem_type(xc_handle, domid, mem_type, 0xc0, 0x40))
+    /* [These numbers] are pfns and page counts [for] the memory ranges:
+       0xc0000 - 0xdffff - VGABIOS and option ROMS (extboot, ethboot, etc)
+       0xf0000 - 0xfffff - the main ROMBIOS */
+    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

... so 0xe0000..0xeffff are the ACPI tables that Jean was wanting the guest to be able to modify. So I should say
+ 0xe0000 - 0xeffff - ACPI tables (guest writes on S3 wakeup)
or some such ?

Forgive my ignorance ...

Ian.

Jean Guyader

author

2008-07-24 10:48 UTC #4 lore raw

In reply to Trolle Selander

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.

Quoted 29 lines · Trolle Selander

Don't leave the main rombios unprotected. I also added a comment to explain the "magic numbers", since their meaning is perhaps not as obvious as I thought, in particular now that we're no longer blanket-protecting the entire firmware area anymore.
/ Trolle
Signed-off-by Trolle Selander <[email protected] <mailto:[email protected]> <mailto:[email protected]>
On Wed, Jul 23, 2008 at 7:02 PM, Ian Jackson <[email protected] <mailto:[email protected]>> wrote:
Jean Guyader writes ("[PATCH] ioemu-remote: ACPI S3 state wake up"):
> ioemu-remote: The device model needs to write in the ACPI tables
when it
> wakes up from S3 state.
I've applied this but I have to say these magic numbers
> - if (xc_hvm_set_mem_type(xc_handle, domid, mem_type,
0xc0, 0x40))
> + if (xc_hvm_set_mem_type(xc_handle, domid, mem_type,
0xc0, 0x20))
are pretty unpleasant! Are they directly derived from addresses specified in ACPI ? I haven't looked ...
Ian.
_______________________________________________
Xen-devel mailing list
[email protected] <mailto:[email protected]>
http://lists.xensource.com/xen-devel

Signature · 1 line

Jean Guyader

Jean Guyader

author

2008-07-24 12:12 UTC #5 lore raw

Quoted 3 lines · Jean Guyader

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 ?

Signature · 1 line

Jean Guyader

Keir Fraser

2008-07-24 12:45 UTC #6 lore raw

Quoted 10 lines · Jean Guyader

Quoted 3 lines · Jean Guyader
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

Trolle Selander

2008-07-24 12:54 UTC #7 lore raw

Was this s3_resume_flag the _only_ thing that needed to be in r/w space, or was that just the only thing in the rombios range? That is - should we revert to the original code, or to the revised version i sent earlier today that protected the actual ROMs but left a r/w gap covering the unused areas and the SMBIOS- & ACPI- tables?

-- Trolle

Quoted 13 lines · Keir Fraser

Quoted 10 lines · Jean Guyader
Quoted 3 lines · Jean Guyader
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 ?

Quoted 9 lines

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
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-24 12:57 UTC #8 lore raw

I think Jean's original and only problem was with the s3_resume_flag.

-- Keir

Quoted 6 lines · Trolle Selander

Was this s3_resume_flag the _only_ thing that needed to be in r/w space, or was that just the only thing in the rombios range? That is - should we revert to the original code, or to the revised version i sent earlier today that protected the actual ROMs but left a r/w gap covering the unused areas and the SMBIOS- & ACPI- tables?

Quoted 26 lines

-- Trolle
Quoted 20 lines · Keir Fraser
Quoted 10 lines · Jean Guyader
Quoted 10 lines
Quoted 3 lines · Jean Guyader
Quoted 3 lines
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
[email protected]
http://lists.xensource.com/xen-devel

Ke, Liping

2008-07-29 09:47 UTC #9 lore raw

In reply to Keir Fraser

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: [email protected] [mailto:[email protected]] 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

Quoted 10 lines · Jean Guyader

Quoted 3 lines · Jean Guyader
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
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-29 09:53 UTC #10 lore raw

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

Quoted 49 lines · Liping

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: [email protected] [mailto:[email protected]] 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
Quoted 10 lines · Jean Guyader
Quoted 3 lines · Jean Guyader
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
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-29 10:26 UTC #11 lore raw

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

Quoted 68 lines · Keir Fraser

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
Quoted 49 lines · Liping
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: [email protected] [mailto:[email protected]] 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
Quoted 10 lines · Jean Guyader
Quoted 3 lines · Jean Guyader
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
[email protected]
http://lists.xensource.com/xen-devel

Ke, Liping

2008-07-29 10:39 UTC #12 lore raw

Hi, Keir
Thanks for the detailed explanation.
Regards,
Criping
-----Original Message-----
From: Keir Fraser [mailto:[email protected]]
Sent: 2008年7月29日 18:26
To: Ke, Liping; Jean Guyader; Trolle Selander; Xu, Jiajun
Cc: xen-devel; Ian Jackson
Subject: Re: [Xen-devel] Re: [PATCH] ioemu-remote: ACPI S3 state wake up

-- Keir

Quoted 68 lines · Keir Fraser

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
Quoted 49 lines · Liping
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: [email protected] [mailto:[email protected]] 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
Quoted 10 lines · Jean Guyader
Quoted 3 lines · Jean Guyader
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
[email protected]
http://lists.xensource.com/xen-devel

Trolle Selander

2008-07-29 10:40 UTC #13 lore raw

In reply to Keir Fraser

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 <[email protected]>

Quoted 78 lines

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
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I removed all
writes
Quoted 1 line
to write-protected ROM regions. If such writes are happening then the
logging
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to the Xen
console.
Quoted 1 line
You may need a debug build of Xen to see them, or add guest_loglvl=all as
a
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash important private
(and in
Quoted 1 line
some cases public) data. Usually it is located just below the VGA
framebuffer,
Quoted 1 line
at around 0x9fc00. Certain parts of it have a well-defined format; other
parts
Quoted 1 line
are completely private to the BIOS. For our purposes all we care about is
that
Quoted 1 line
we do not write-protect it, and we just stash an extra 8-bit variable
within
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 3 lines
Quoted 3 lines
exist.
Just did some debugging, from ITP, one cpu is in default_idle loop,
other one
Quoted 1 line
Quoted 1 line
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc. So I think
this
Quoted 15 lines
Quoted 15 lines
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: [email protected] [mailto:[email protected]] 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
Quoted 5 lines
Quoted 5 lines · Jean Guyader
Quoted 4 lines
Quoted 2 lines · Jean Guyader
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
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 1 line
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 ?

Quoted 17 lines

Quoted 1 line
Quoted 1 line
In that case the changes to ioemu-remote should be reverted. The correct
fix
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have committed this fix
as
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ke, Liping

2008-07-29 11:22 UTC #14 lore raw

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:[email protected]]
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

-- Trolle
2008/7/29 Keir Fraser <[email protected]>
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

Quoted 15 lines · Keir Fraser

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.

Quoted 53 lines

-- Keir
Quoted 49 lines · Liping
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: [email protected] [mailto:[email protected]] 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
Quoted 10 lines · Jean Guyader
Quoted 3 lines · Jean Guyader
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
[email protected]
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-29 11:50 UTC #15 lore raw

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

Quoted 116 lines · Liping

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:[email protected]]
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 <[email protected]>
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
Quoted 73 lines · Keir Fraser
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
Quoted 51 lines · Liping
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: [email protected] [mailto:[email protected]] 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
Quoted 10 lines · Jean Guyader
Quoted 3 lines · Jean Guyader
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
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-29 11:50 UTC #16 lore raw

In reply to Trolle Selander

Yes, good point, but yet the POST still happens. :-) I wonder why...

-- Keir

Quoted 6 lines · Trolle Selander

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?

Quoted 21 lines

-- Trolle
2008/7/29 Keir Fraser <[email protected]>
Quoted 18 lines
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
Quoted 9 lines · Keir Fraser
Quoted 3 lines
Hi,
I didn't actually test cs18120, so I'm not certain that I removed all
writes
Quoted 1 line
to write-protected ROM regions. If such writes are happening then the
logging
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to the Xen
console.
Quoted 1 line
You may need a debug build of Xen to see them, or add guest_loglvl=all as

Quoted 46 lines

Quoted 46 lines
Quoted 46 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash important private (and
in
Quoted 1 line
some cases public) data. Usually it is located just below the VGA
framebuffer,
Quoted 1 line
at around 0x9fc00. Certain parts of it have a well-defined format; other
parts
Quoted 1 line
are completely private to the BIOS. For our purposes all we care about is
that
Quoted 1 line
we do not write-protect it, and we just stash an extra 8-bit variable
within
Quoted 5 lines
it to indicate if this is a warm return from S3.
-- Keir
On 29/7/08 10:47, "Ke, Liping" <liping.ke <http://liping.ke> @intel.com
Quoted 28 lines · <http://intel.com> > wrote:
Quoted 6 lines
Quoted 6 lines
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
Quoted 3 lines
Quoted 3 lines
exist.
Just did some debugging, from ITP, one cpu is in default_idle loop,
other one
Quoted 1 line
Quoted 1 line
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc. So I think
this
Quoted 15 lines
Quoted 15 lines
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: [email protected] [mailto:[email protected]] 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

Quoted 4 lines

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines · Jean Guyader
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
Quoted 1 line
I already tried to reduce the rw area, and just keep 0xe0 -> 0xef.

But

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to write on this
frame
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
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

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
rombios
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be reverted. The correct
fix
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have committed this fix

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
xen-unstable.hg:18120.
-- Keir

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-29 11:58 UTC #17 lore raw

Ah, S3 is special-cased in machine_reset(). Nice.

-- Keir

Quoted 33 lines · Keir Fraser

Yes, good point, but yet the POST still happens. :-) I wonder why...
-- Keir
Quoted 27 lines · Trolle Selander
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 <[email protected]>
Quoted 18 lines
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
Quoted 9 lines · Keir Fraser
Quoted 3 lines
Hi,
I didn't actually test cs18120, so I'm not certain that I removed all
writes
Quoted 1 line
to write-protected ROM regions. If such writes are happening then the
logging
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to the Xen
console.
Quoted 1 line
You may need a debug build of Xen to see them, or add guest_loglvl=all as

Quoted 38 lines

Quoted 38 lines
Quoted 38 lines
Quoted 38 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash important private
(and in
Quoted 1 line
some cases public) data. Usually it is located just below the VGA
framebuffer,
Quoted 1 line
at around 0x9fc00. Certain parts of it have a well-defined format; other
parts
Quoted 1 line
are completely private to the BIOS. For our purposes all we care about is
that
Quoted 1 line
we do not write-protect it, and we just stash an extra 8-bit variable
within
Quoted 5 lines
it to indicate if this is a warm return from S3.
-- Keir
On 29/7/08 10:47, "Ke, Liping" <liping.ke <http://liping.ke> @intel.com
Quoted 20 lines · <http://intel.com> > wrote:
Quoted 6 lines
Quoted 6 lines
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
Quoted 3 lines
Quoted 3 lines
exist.
Just did some debugging, from ITP, one cpu is in default_idle loop,
other one
Quoted 1 line
Quoted 1 line
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc. So I think
this
Quoted 7 lines
Quoted 7 lines
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

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines · Jean Guyader
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
Quoted 1 line
I already tried to reduce the rw area, and just keep 0xe0 -> 0xef.

But

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to write on this
frame
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
Quoted 1 line
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

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
rombios
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be reverted. The
correct fix
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have committed this fix

Quoted 17 lines

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
xen-unstable.hg:18120.
-- Keir
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Quoted 4 lines

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-29 15:11 UTC #18 lore raw

In reply to Keir Fraser

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

Quoted 89 lines · Keir Fraser

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
Quoted 18 lines · Keir Fraser
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.
Quoted 55 lines
-- Keir
Quoted 51 lines · Liping
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: [email protected] [mailto:[email protected]] 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
Quoted 10 lines · Jean Guyader
Quoted 3 lines · Jean Guyader
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
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ke, Liping

2008-07-30 02:51 UTC #19 lore raw

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:[email protected]]
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

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

Quoted 89 lines · Keir Fraser

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
Quoted 18 lines · Keir Fraser
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.
Quoted 55 lines
-- Keir
Quoted 51 lines · Liping
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: [email protected] [mailto:[email protected]] 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
Quoted 10 lines · Jean Guyader
Quoted 3 lines · Jean Guyader
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
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Tian, Kevin

2008-07-30 03:09 UTC #20 lore raw

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

Quoted 159 lines

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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On 24/7/08 13:12, "Jean Guyader"
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ke, Liping

2008-07-30 04:48 UTC #21 lore raw

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

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. :-)

Thanks,
Kevin

Quoted 159 lines

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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On 24/7/08 13:12, "Jean Guyader"
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ke, Liping

2008-07-30 11:44 UTC #22 lore raw

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: [email protected] [mailto:[email protected]] 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

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. :-)

Thanks,
Kevin

Quoted 154 lines

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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On 24/7/08 13:12, "Jean Guyader"
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Quoted 5 lines

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-30 12:01 UTC #23 lore raw

That's interesting. For me, the upcall works fine and I get the correct vector back to s3_resume(). My problems seem to occur after control has returned to the guest OS.

-- Keir

Quoted 344 lines · Liping

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: [email protected] [mailto:[email protected]] 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
Quoted 154 lines
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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On 24/7/08 13:12, "Jean Guyader"
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 5 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ke, Liping

2008-07-30 11:50 UTC #24 lore raw

In reply to Ke, Liping

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

(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

Any input is warmly welcome, really not familiar with asm code in 32bitgateway -:) Thanks a lot!
Criping

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

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. :-)

Thanks,
Kevin

Quoted 154 lines

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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On 24/7/08 13:12, "Jean Guyader"
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Quoted 5 lines

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-30 12:05 UTC #25 lore raw

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

Quoted 353 lines · Liping

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: [email protected] [mailto:[email protected]] 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
Quoted 154 lines
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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On 24/7/08 13:12, "Jean Guyader"
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 5 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Ke, Liping

2008-07-31 10:25 UTC #26 lore raw

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:[email protected]]
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

-- Keir

Quoted 353 lines · Liping

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: [email protected] [mailto:[email protected]] 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
Quoted 154 lines
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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On 24/7/08 13:12, "Jean Guyader"
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 5 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Jean Guyader

author

2008-07-31 10:28 UTC #27 lore raw

Hi,

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

Regards,

Quoted 380 lines · Liping

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:[email protected]]
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
Quoted 341 lines · Liping
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: [email protected] [mailto:[email protected]] 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
Quoted 147 lines
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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
On 24/7/08 13:12, "Jean Guyader"
Quoted 2 lines · <[email protected]> wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 12 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 5 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Signature · 1 line

Jean Guyader

Keir Fraser

2008-07-31 10:43 UTC #28 lore raw

In reply to Ke, Liping

There's a race in rombios/Makefile which could cause the rombios to be re-built befor the 32bit parts have been re-generated. If you re-made your rombios only once, and then started debugging it without ever re-making it again, you could then see this issue. If you had at any point re-made your rombios a second time, the issue would most likely have gone away. :-)

-- Keir

Quoted 391 lines · Liping

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:[email protected]]
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
Quoted 356 lines · Liping
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: [email protected] [mailto:[email protected]] 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
Quoted 154 lines
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:[email protected]]
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
Quoted 1 line · Keir Fraser
I can reproduce the issue. It's two things: firstly certain
ACPI tables do
Quoted 1 line
need to be writable (e.g., firmware_waking_vector).
Secondly, when the BIOS
Quoted 1 line
re-POSTs it is writing to itself, which we allow on initial
boot but not on
Quoted 9 lines
warm reset. That needs fixing. I'll take a look at doing so.
-- Keir
Quoted 3 lines · Keir Fraser
Hi,
I didn't actually test cs18120, so I'm not certain that I
removed all writes
Quoted 1 line
Quoted 1 line
to write-protected ROM regions. If such writes are
happening then the logging
Quoted 1 line
Quoted 1 line
at line 1510 in xen/arch/x86/hvm/hvm.c should be printed to
the Xen console.
Quoted 1 line
Quoted 1 line
You may need a debug build of Xen to see them, or add
guest_loglvl=all as a
Quoted 3 lines
Quoted 3 lines
Xen boot parameter.
The EBDA is simply a RAM area for the BIOS to stash
important private (and in
Quoted 3 lines
Quoted 3 lines
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
Quoted 2 lines
Quoted 2 lines
parts
are completely private to the BIOS. For our purposes all we
care about is
Quoted 2 lines
Quoted 2 lines
that
we do not write-protect it, and we just stash an extra
8-bit variable within
Quoted 11 lines
Quoted 11 lines
it to indicate if this is a warm return from S3.
-- Keir
Quoted 5 lines · Liping
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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
still
exist.
Just did some debugging, from ITP, one cpu is in
default_idle loop, other
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
one
is for-ever running in x86_emulate/memcpy/__hvm_copy, etc.
So I think this
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
might be the same problem Guyader meet before?
I am not familiar about EBDA, could somebody help me to
have a look?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Thanks& Regards,
Criping
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Keir Fraser
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On 24/7/08 13:12, "Jean Guyader"
Quoted 3 lines · <[email protected]> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line · Jean Guyader
I already tried to reduce the rw area, and just keep
0xe0 -> 0xef. But
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
obviously it doesn't work the device model needs to
write on this frame
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
0xf1. I still don't figure out why.
The rombios write on this page because of this flags
s3_resume_flag
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(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
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
as rw just because of that.
Any suggestions ?
In that case the changes to ioemu-remote should be
reverted. The correct fix
Quoted 1 line
Quoted 1 line
Quoted 1 line
is to move the S3 resume flag into the EBDA. I have
committed this fix as
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
xen-unstable.hg:18120.
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 5 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel