[PATCH 3/4] rombios interface for HVM S3
- add S3 package in ACPI DSDT table. Guest OS will get S3 value from
this package and write the value to PM1A control register to
trigger S3 suspend.
- Add S3 resume logic in rombios post code. the CMOS shutdown
register is used to indicate if this is a S3 resume.
- if it is s3 resume, rombios will get wakeup vector from ACPI FACS
table and jump to wakeup vector. Per ACPI spec, the wakeup vector
jumping must be the forms CS:IP, in which CS=(wakeup vector>>4)
IP=(wakeup vector)&0xF, for example, for vector=0x12345,
CS:IP=0x1234:0x5
Note: clobber_entry_point will clobber the post entry, which make S3
resume not work. We will directly jmp to POST Entry if it in S3
Resume path.
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Ke Liping <liping.ke@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
This patch has no change. [PATCH 3/4] rombios interface for HVM S3 - add S3 package in ACPI DSDT table. Guest OS will get S3 value from this package and write the value to PM1A control register to trigger S3 suspend. - Add S3 resume logic in rombios post code. the CMOS shutdown register is used to indicate if this is a S3 resume. - if it is s3 resume, rombios will get wakeup vector from ACPI FACS table and jump to wakeup vector. Per ACPI spec, the wakeup vector jumping must be the forms CS:IP, in which CS=(wakeup vector>>4) IP=(wakeup vector)&0xF, for example, for vector=0x12345, CS:IP=0x1234:0x5 Note: clobber_entry_point will clobber the post entry, which make S3 resume not work. We will directly jmp to POST Entry if it in S3 Resume path. Signed-off-by: Yu Ke <ke.yu@intel.com> Signed-off-by: Ke Liping <liping.ke@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
"Ke, Liping" wrote:> This patch has no change. > > [PATCH 3/4] rombios interface for HVM S3 > - add S3 package in ACPI DSDT table. Guest OS will get S3 value from > this package and write the value to PM1A control register to trigger S3 > suspend. > - Add S3 resume logic in rombios post code. the CMOS shutdown register > is used to indicate if this is a S3 resume. > - if it is s3 resume, rombios will get wakeup vector from ACPI FACS > table and jump to wakeup vector.Has anyone tested this with an AMD cpu? I suspect that the code was tested with Intel CPUs; and reading old mailing list messages, it seems to be able to s3resume both linux and windows hvm guests on intel vtd. With an amd64 x2 cpu (using an opensolaris dom0), the hvm bios seems to hang in rombios.c when I use "xm trigger domain s3resume", here: /* get x_firmware_waking_vector */ s3_wakeup_vector = *((Bit16u*)(ACPI_FACS_ADDRESS+ACPI_FACS_OFFSET+24)); Matching the CS:IP (f000:1692) listed in the xen console''s register dump with the xen.hg/tools/firmware/rombios/rombios.txt file, we''re at this instruction: 06098 ! 1816 06099 ! 1817 06100 ! 1818 s3_wakeup_vector = *((Bit16u*)(0xEA000 +0x10 +24)); 06101 ! Debug: eq unsigned short = [+$EA028] to unsigned short s3_wakeup_vector = [S+4-4] (used reg = ) 06102 1692 67 A1 000EA028 mov ax,[$EA028] Any address >= 0x10000 (e.g. 0x000EA028) hangs in the bios on my box. 0xfffe works ok - that doesn''t use the 67 prefix byte and uses a 16 bit address.> Per ACPI spec, the wakeup vector > jumping must be the forms CS:IP, in which CS=(wakeup vector>>4) > IP=(wakeup vector)&0xF, for example, for vector=0x12345, > CS:IP=0x1234:0x5Hmm, the current code in s3_resume() reads a 16-bit value from the FACS wakeup vector fields (see rombios.c, lines 2317 / 2342). A vector like 0x12345 wouldn''t work at this time, because it gets truncated to 0x2345! I''d say we need to load at least a 20-bit value from ACPI_FACS_ADDRESS+ACPI_FACS_OFFSET+12 (and the x_firmware_waking_vector is supposed to be a 64-bit physical address, so that proably needs more changes). 2314 void 2315 s3_resume() 2316 { 2317 Bit16u s3_wakeup_vector; ... 2338 /* get x_firmware_waking_vector */ 2339 s3_wakeup_vector = *((Bit16u*)(ACPI_FACS_ADDRESS+ACPI_FACS_OFFSET+24)); 2340 if (s3_wakeup_vector == 0){ 2341 /* get firmware_waking_vector */ 2342 s3_wakeup_vector = *((Bit16u*)(ACPI_FACS_ADDRESS+ACPI_FACS_OFFSET+12)); 2343 if (s3_wakeup_vector == 0){ 2344 goto s3_out; 2345 } 2346 } 2347 2348 /* setup wakeup vector */ 2349 s3_wakeup_ip = s3_wakeup_vector & 0xF; 2350 s3_wakeup_cs = s3_wakeup_vector >> 4; Another thing that looks strange is that s3_wakeup_ip / s3_wakeup_cs must be copied from segment #0000 to #f000 (lines 2353-2359). I''d say the s3_resume code could corrupt some random 4-bytes in the lower 64 kbyte segment: (DS = #0x0000 at this point ->) 2348 /* setup wakeup vector */ 2349 s3_wakeup_ip = s3_wakeup_vector & 0xF; 2350 s3_wakeup_cs = s3_wakeup_vector >> 4; 2351 2352 ASM_START 2353 mov bx, [_s3_wakeup_cs] 2354 mov dx, [_s3_wakeup_ip] 2355 2356 mov ax, #0xF000 2357 mov ds, ax 2358 mov [_s3_wakeup_cs], bx 2359 mov [_s3_wakeup_ip], dx 2360 jmpf [_s3_wakeup_ip] For now I''m using the attached patch. It doesn''t hang any more in the bios on s3resume, and the standard firmware_waking_vector can point anywere in memory below 1MB. And it doesn''t write to 0000:_s3_wakeup_{cs,ip} any more. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jun-02 14:14 UTC
Re: [Xen-devel] [PATCH 3/4] rombios interface for HVM S3
On 2/6/08 14:45, "Juergen Keil" <jk@tools.de> wrote:> For unknown reasons, HVM S3 resume hangs in the bios when trying to load > the x_firmware_waking_vector from absolute address 0xEA01C (it hangs for > access to address 0x10000, but doesn''t hang for 0xfffe).It works on Intel because there we emulate the rombios, and our emulator does not bother with segment limit checks in real mode. This is actually more lenient than real hardware, hence an AMD CPU (which is directly executing the rombios code) will fault on the access because it is at a segment offset greater than 64kB. Your patch is good. Please re-submit with a fixed changeset comment and a signed-off-by line. I''ll then check it in. Thanks, Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Juergen Keil
2008-Jun-02 14:50 UTC
Re: [Xen-devel] [PATCH 3/4] rombios interface for HVM S3
Keir Fraser wrote:> On 2/6/08 14:45, "Juergen Keil" <jk@tools.de> wrote: > > > For unknown reasons, HVM S3 resume hangs in the bios when trying to load > > the x_firmware_waking_vector from absolute address 0xEA01C (it hangs for > > access to address 0x10000, but doesn''t hang for 0xfffe). > > It works on Intel because there we emulate the rombios, and our emulator > does not bother with segment limit checks in real mode. This is actually > more lenient than real hardware, hence an AMD CPU (which is directly > executing the rombios code) will fault on the access because it is at a > segment offset greater than 64kB. > > Your patch is good. Please re-submit with a fixed changeset comment and a > signed-off-by line. I''ll then check it in.Ok, comment is updated, see the attachment. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel