Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
-8--
From 2d1b814e65676c3cf56ce2e569491953607f53f7 Mon Sep 17 00:00:00 2001
From: Ian Campbell ian.campb...@citrix.com
Date: Fri, 29 May 2015 13:51:33 +0100
Subject: [PATCH] Turn off acpi_shutdown for windows 7
As described in 1432284841.10746.136.ca...@citrix.com /
http://lists.xen.org/archives/html/xen-devel/2015-05/msg03016.html
Windows 7 does not appear to reliably actually shutdown when asked to
via the ACPI power button.
Once this patch is applied some force pushes will likely be needed in
order for this to not appear as a regression.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Paul Durrant paul.durr...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com,
Cc: Jan Beulich jbeul...@suse.com
---
Alternatively could make it an allowed/non-blocking failure?
---
make-flight | 1 -
1 file changed, 1 deletion(-)
diff --git a/make-flight b/make-flight
index 8a1fceb..5120891 100755
--- a/make-flight
+++ b/make-flight
@@ -206,7 +206,6 @@ do_hvm_win7_x64_tests () {
job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-win7-amd64 \
test-win xl $xenarch $dom0arch $qemuu_runvar \
win_image=win7-x64.iso \
-win_acpi_shutdown=true \
all_hostflags=$most_hostflags,hvm
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-29 at 14:14 +0100, Andrew Cooper wrote:
On 29/05/15 14:04, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
You can avoid advertising S3/S4 in the ACPI tables, which iirc causes
the same alteration to happen.
Hvmloader uses the platform/acpi_s{3,4} booleans to control whether the
relevant SSDTs are exposed.
As I said in 1432285699.10746.147.ca...@citrix.com and again in reply
to Jan just now, this test does sometimes pass.
So whether or not we are exposing the correct set of tables to the guest
there is something else non-deterministic going on here I think.
I'd also be concerned about the impact on other tests (in particular the
SRM ones) on disabling s3 and/or s4.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
Jan
-8--
From 2d1b814e65676c3cf56ce2e569491953607f53f7 Mon Sep 17 00:00:00 2001
From: Ian Campbell ian.campb...@citrix.com
Date: Fri, 29 May 2015 13:51:33 +0100
Subject: [PATCH] Turn off acpi_shutdown for windows 7
As described in 1432284841.10746.136.ca...@citrix.com /
http://lists.xen.org/archives/html/xen-devel/2015-05/msg03016.html
Windows 7 does not appear to reliably actually shutdown when asked to
via the ACPI power button.
Once this patch is applied some force pushes will likely be needed in
order for this to not appear as a regression.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Paul Durrant paul.durr...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com,
Cc: Jan Beulich jbeul...@suse.com
---
Alternatively could make it an allowed/non-blocking failure?
---
make-flight | 1 -
1 file changed, 1 deletion(-)
diff --git a/make-flight b/make-flight
index 8a1fceb..5120891 100755
--- a/make-flight
+++ b/make-flight
@@ -206,7 +206,6 @@ do_hvm_win7_x64_tests () {
job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-win7-amd64 \
test-win xl $xenarch $dom0arch $qemuu_runvar \
win_image=win7-x64.iso \
-win_acpi_shutdown=true \
all_hostflags=$most_hostflags,hvm
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-29 at 14:04 +0100, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
The strange this is that it does work _sometimes_, either by complete
coincidence or because there is something non-deterministic about how
Win7 reacts to this ACPI event.
Does anyone know which setting we would want to change? In particular it
would be good if I knew what to look for to check the current status...
Jan
-8--
From 2d1b814e65676c3cf56ce2e569491953607f53f7 Mon Sep 17 00:00:00 2001
From: Ian Campbell ian.campb...@citrix.com
Date: Fri, 29 May 2015 13:51:33 +0100
Subject: [PATCH] Turn off acpi_shutdown for windows 7
As described in 1432284841.10746.136.ca...@citrix.com /
http://lists.xen.org/archives/html/xen-devel/2015-05/msg03016.html
Windows 7 does not appear to reliably actually shutdown when asked to
via the ACPI power button.
Once this patch is applied some force pushes will likely be needed in
order for this to not appear as a regression.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Paul Durrant paul.durr...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com,
Cc: Jan Beulich jbeul...@suse.com
---
Alternatively could make it an allowed/non-blocking failure?
---
make-flight | 1 -
1 file changed, 1 deletion(-)
diff --git a/make-flight b/make-flight
index 8a1fceb..5120891 100755
--- a/make-flight
+++ b/make-flight
@@ -206,7 +206,6 @@ do_hvm_win7_x64_tests () {
job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-win7-amd64 \
test-win xl $xenarch $dom0arch $qemuu_runvar \
win_image=win7-x64.iso \
-win_acpi_shutdown=true \
all_hostflags=$most_hostflags,hvm
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 29.05.15 at 15:14, andrew.coop...@citrix.com wrote:
On 29/05/15 14:04, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
You can avoid advertising S3/S4 in the ACPI tables, which iirc causes
the same alteration to happen.
Hvmloader uses the platform/acpi_s{3,4} booleans to control whether the
relevant SSDTs are exposed.
Which libxl even has settings for. That would perhaps be a better first
try than disabling ACPI shutdown.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 29/05/15 14:04, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
You can avoid advertising S3/S4 in the ACPI tables, which iirc causes
the same alteration to happen.
Hvmloader uses the platform/acpi_s{3,4} booleans to control whether the
relevant SSDTs are exposed.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-29 at 14:28 +0100, Jan Beulich wrote:
On 29.05.15 at 15:14, andrew.coop...@citrix.com wrote:
On 29/05/15 14:04, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
You can avoid advertising S3/S4 in the ACPI tables, which iirc causes
the same alteration to happen.
Hvmloader uses the platform/acpi_s{3,4} booleans to control whether the
relevant SSDTs are exposed.
Which libxl even has settings for. That would perhaps be a better first
try than disabling ACPI shutdown.
I've mentioned it at least twice now but nobody seems to think it is of
note that even with the current settings it does the right thing about 1
time in 10? Is Win7 really expected to behave so randomly here?
Also, when the test fails the guest is also not hibernating either.
Plus I've queried the impact of change the ACPI s3/s4 settings on the
save/restore/migrate tests in the flight more than once and nobody has
responded to that either.
Ian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-29 at 15:31 +0100, Andrew Cooper wrote:
On 29/05/15 15:00, Ian Campbell wrote:
On Fri, 2015-05-29 at 14:28 +0100, Jan Beulich wrote:
On 29.05.15 at 15:14, andrew.coop...@citrix.com wrote:
On 29/05/15 14:04, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such
changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
You can avoid advertising S3/S4 in the ACPI tables, which iirc causes
the same alteration to happen.
Hvmloader uses the platform/acpi_s{3,4} booleans to control whether the
relevant SSDTs are exposed.
Which libxl even has settings for. That would perhaps be a better first
try than disabling ACPI shutdown.
I've mentioned it at least twice now but nobody seems to think it is of
note that even with the current settings it does the right thing about 1
time in 10? Is Win7 really expected to behave so randomly here?
Windows is far from bug free, and also a black box. I really cannot
answer whether this is intended behaviour or not.
Also, when the test fails the guest is also not hibernating either.
Plus I've queried the impact of change the ACPI s3/s4 settings on the
save/restore/migrate tests in the flight more than once and nobody has
responded to that either.
save/restore/migrate necessarily need PV drivers inside the guest, and
installing PV drivers should set the sane defaults inside the guest.
What does OSSTest do with PV drivers?
Nothing AFAIK, unless they are baked into the ISOs we take from the
XenRT folks (which I think is not the case).
Yet our s/r/m tests of these guests do pass (mostly), I believe because
they end up leveraging HVM s3 but I might be wrong.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
-Original Message- From: Paul Durrant Sent: 29 May 2015 16:07 To: Ian Campbell Cc: Jan Beulich; Andrew Cooper; Ian Jackson; xen-devel Subject: RE: [Xen-devel] ACPI shutdown unreliable with win7? -Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: 29 May 2015 15:36 To: Paul Durrant Cc: Jan Beulich; Andrew Cooper; Ian Jackson; xen-devel Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On Fri, 2015-05-29 at 15:25 +0100, Paul Durrant wrote: -Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: 29 May 2015 14:14 To: Jan Beulich Cc: Andrew Cooper; Paul Durrant; Ian Jackson; xen-devel Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On Fri, 2015-05-29 at 14:04 +0100, Jan Beulich wrote: On 29.05.15 at 14:54, ian.campb...@citrix.com wrote: On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote: If win7 doesn't shutdown given a power button request I'd be more inclined to remove the setting in osstest for those flights and let guest-stop go back to being never pass than to start making such changes to the VM config which I think would probably break the preceding suspend and migration tests (which aren't completely reliable, but are far more so than this shutdown one). Does anyone have any ideas here or shall I propose: Unless we have a way to make an adjustment inside the guest for the power button to gain shutdown meaning, I think there's no alternative to the change below. The strange this is that it does work _sometimes_, either by complete coincidence or because there is something non-deterministic about how Win7 reacts to this ACPI event. How long is the test waiting for the OS to shut down though? If you get unlucky, Windows will wander off to Windows Update, download a bazillion patches and take more than an hour to shut down. If you’re lucky, it may shut down in 10 seconds or less. The screenshot in e.g. http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64- amd64- xl-qemut-win7-amd64/info.html seems to show that the guest isn't even trying to shut down, it's just sat there at the desktop: http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64- amd64- xl-qemut-win7-amd64/win.guest.osstest--vnc.jpeg I think if it had hit WU there would be activity on the screen? FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? I already said this to Ian, but for the record... From my reading of the ACPI spec (v 5.0, page 23 glossary entry) the SCI is an active low, shareable, level-sensitive interrupt, but our code (pmtimer.c:pmt_update_sci) seems to treat it as active high. I'll have a look at the QEMU SCI code as reference, but maybe it is just broken. Paul Paul Ian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
-Original Message- From: Ross Philipson [mailto:ross.philip...@gmail.com] Sent: 29 May 2015 16:35 To: Ian Campbell; Paul Durrant Cc: Andrew Cooper; xen-devel; Jan Beulich; Ian Jackson Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On 05/29/2015 11:11 AM, Ian Campbell wrote: On Fri, 2015-05-29 at 16:06 +0100, Paul Durrant wrote: FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? It seems to work reliably for the WinXP tests, FWIW... Ian. One thing I find confusing is that the firmware code does not even have a power button device (PNP0C0C) or the fixed feature power button that is enabled in the FADT (flag == PWR_BUTTON bit 4). So I don't see how the shutdown is purely an ACPI function. Is there something else to the story? Is it relying on PV tools to do it? Xen (and QEMU seemingly) implement the 'Fixed Power Button' (section 4.8.2.2.1.1 on my spec) and this requires the PWR_BUTTON flag to be clear (according table 4-13). It also does not require a power button device to be implemented (which is presumably why this way of doing it was chosen). Paul Ross ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel -- Ross Philipson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 05/29/2015 12:00 PM, Paul Durrant wrote: -Original Message- From: Ross Philipson [mailto:ross.philip...@gmail.com] Sent: 29 May 2015 16:35 To: Ian Campbell; Paul Durrant Cc: Andrew Cooper; xen-devel; Jan Beulich; Ian Jackson Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On 05/29/2015 11:11 AM, Ian Campbell wrote: On Fri, 2015-05-29 at 16:06 +0100, Paul Durrant wrote: FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? It seems to work reliably for the WinXP tests, FWIW... Ian. One thing I find confusing is that the firmware code does not even have a power button device (PNP0C0C) or the fixed feature power button that is enabled in the FADT (flag == PWR_BUTTON bit 4). So I don't see how the shutdown is purely an ACPI function. Is there something else to the story? Is it relying on PV tools to do it? Xen (and QEMU seemingly) implement the 'Fixed Power Button' (section 4.8.2.2.1.1 on my spec) and this requires the PWR_BUTTON flag to be clear (according table 4-13). It also does not require a power button device to be implemented (which is presumably why this way of doing it was chosen). Ah got it. I read the spec backwards - that the bit was set not clear for the fixed feature power button :) Paul Ross ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel -- Ross Philipson -- Ross Philipson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 05/29/2015 11:11 AM, Ian Campbell wrote: On Fri, 2015-05-29 at 16:06 +0100, Paul Durrant wrote: FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? It seems to work reliably for the WinXP tests, FWIW... Ian. One thing I find confusing is that the firmware code does not even have a power button device (PNP0C0C) or the fixed feature power button that is enabled in the FADT (flag == PWR_BUTTON bit 4). So I don't see how the shutdown is purely an ACPI function. Is there something else to the story? Is it relying on PV tools to do it? Ross ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel -- Ross Philipson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 29.05.15 at 16:00, ian.campb...@citrix.com wrote:
On Fri, 2015-05-29 at 14:28 +0100, Jan Beulich wrote:
On 29.05.15 at 15:14, andrew.coop...@citrix.com wrote:
On 29/05/15 14:04, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
You can avoid advertising S3/S4 in the ACPI tables, which iirc causes
the same alteration to happen.
Hvmloader uses the platform/acpi_s{3,4} booleans to control whether the
relevant SSDTs are exposed.
Which libxl even has settings for. That would perhaps be a better first
try than disabling ACPI shutdown.
I've mentioned it at least twice now but nobody seems to think it is of
note that even with the current settings it does the right thing about 1
time in 10? Is Win7 really expected to behave so randomly here?
Perhaps not expected, but then I also don't think we install all the
latest bits, but whatever is on the install media? I know I've seen the
default action preselected for the user to be different on different
instances of native hardware Win7 installs (but of course that could
as well have been due to firmware differences, albeit I doubt there's
many moder systems around that don't support both S3 and S4).
Also, when the test fails the guest is also not hibernating either.
Would we have ways to tell it at least tried to enter e.g. S3?
Plus I've queried the impact of change the ACPI s3/s4 settings on the
save/restore/migrate tests in the flight more than once and nobody has
responded to that either.
I have no idea, and hence didn't respond to that part.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
-Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: 29 May 2015 15:36 To: Paul Durrant Cc: Jan Beulich; Andrew Cooper; Ian Jackson; xen-devel Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On Fri, 2015-05-29 at 15:25 +0100, Paul Durrant wrote: -Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: 29 May 2015 14:14 To: Jan Beulich Cc: Andrew Cooper; Paul Durrant; Ian Jackson; xen-devel Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On Fri, 2015-05-29 at 14:04 +0100, Jan Beulich wrote: On 29.05.15 at 14:54, ian.campb...@citrix.com wrote: On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote: If win7 doesn't shutdown given a power button request I'd be more inclined to remove the setting in osstest for those flights and let guest-stop go back to being never pass than to start making such changes to the VM config which I think would probably break the preceding suspend and migration tests (which aren't completely reliable, but are far more so than this shutdown one). Does anyone have any ideas here or shall I propose: Unless we have a way to make an adjustment inside the guest for the power button to gain shutdown meaning, I think there's no alternative to the change below. The strange this is that it does work _sometimes_, either by complete coincidence or because there is something non-deterministic about how Win7 reacts to this ACPI event. How long is the test waiting for the OS to shut down though? If you get unlucky, Windows will wander off to Windows Update, download a bazillion patches and take more than an hour to shut down. If you’re lucky, it may shut down in 10 seconds or less. The screenshot in e.g. http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64-amd64- xl-qemut-win7-amd64/info.html seems to show that the guest isn't even trying to shut down, it's just sat there at the desktop: http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64-amd64- xl-qemut-win7-amd64/win.guest.osstest--vnc.jpeg I think if it had hit WU there would be activity on the screen? FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? Paul Ian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-29 at 16:06 +0100, Paul Durrant wrote: FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? It seems to work reliably for the WinXP tests, FWIW... Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
-Original Message- From: Paul Durrant Sent: 29 May 2015 16:35 To: Ian Campbell Cc: 'Jan Beulich'; Andrew Cooper; Ian Jackson; 'xen-devel' Subject: RE: [Xen-devel] ACPI shutdown unreliable with win7? -Original Message- From: Paul Durrant Sent: 29 May 2015 16:07 To: Ian Campbell Cc: Jan Beulich; Andrew Cooper; Ian Jackson; xen-devel Subject: RE: [Xen-devel] ACPI shutdown unreliable with win7? -Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: 29 May 2015 15:36 To: Paul Durrant Cc: Jan Beulich; Andrew Cooper; Ian Jackson; xen-devel Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On Fri, 2015-05-29 at 15:25 +0100, Paul Durrant wrote: -Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: 29 May 2015 14:14 To: Jan Beulich Cc: Andrew Cooper; Paul Durrant; Ian Jackson; xen-devel Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On Fri, 2015-05-29 at 14:04 +0100, Jan Beulich wrote: On 29.05.15 at 14:54, ian.campb...@citrix.com wrote: On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote: If win7 doesn't shutdown given a power button request I'd be more inclined to remove the setting in osstest for those flights and let guest-stop go back to being never pass than to start making such changes to the VM config which I think would probably break the preceding suspend and migration tests (which aren't completely reliable, but are far more so than this shutdown one). Does anyone have any ideas here or shall I propose: Unless we have a way to make an adjustment inside the guest for the power button to gain shutdown meaning, I think there's no alternative to the change below. The strange this is that it does work _sometimes_, either by complete coincidence or because there is something non-deterministic about how Win7 reacts to this ACPI event. How long is the test waiting for the OS to shut down though? If you get unlucky, Windows will wander off to Windows Update, download a bazillion patches and take more than an hour to shut down. If you’re lucky, it may shut down in 10 seconds or less. The screenshot in e.g. http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64- amd64- xl-qemut-win7-amd64/info.html seems to show that the guest isn't even trying to shut down, it's just sat there at the desktop: http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64- amd64- xl-qemut-win7-amd64/win.guest.osstest--vnc.jpeg I think if it had hit WU there would be activity on the screen? FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? I already said this to Ian, but for the record... From my reading of the ACPI spec (v 5.0, page 23 glossary entry) the SCI is an active low, shareable, level- sensitive interrupt, but our code (pmtimer.c:pmt_update_sci) seems to treat it as active high. I'll have a look at the QEMU SCI code as reference, but maybe it is just broken. Upstream QEMU does seem to have it the same way up as our pmtimer code (hw/acpi/core.c:acpi_update_sci) so at least we're in good company :-/ Paul Paul Paul Ian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 29.05.15 at 17:34, paul.durr...@citrix.com wrote: From: Paul Durrant Sent: 29 May 2015 16:07 No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? I already said this to Ian, but for the record... From my reading of the ACPI spec (v 5.0, page 23 glossary entry) the SCI is an active low, shareable, level-sensitive interrupt, but our code (pmtimer.c:pmt_update_sci) seems to treat it as active high. I'll have a look at the QEMU SCI code as reference, but maybe it is just broken. While ACPI may prefer it to be that way, I don't think this is a requirement (both physical systems I checked just now have it level-high), and in any case subject to an interrupt source override in MADT (which hvmloader doesn't produce afaict). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 05/29/2015 12:00 PM, Paul Durrant wrote: -Original Message- From: Ross Philipson [mailto:ross.philip...@gmail.com] Sent: 29 May 2015 16:35 To: Ian Campbell; Paul Durrant Cc: Andrew Cooper; xen-devel; Jan Beulich; Ian Jackson Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On 05/29/2015 11:11 AM, Ian Campbell wrote: On Fri, 2015-05-29 at 16:06 +0100, Paul Durrant wrote: FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. No, you'd see something. Perhaps our ACPI lid/power switch code is just buggy then? It seems to work reliably for the WinXP tests, FWIW... Ian. One thing I find confusing is that the firmware code does not even have a power button device (PNP0C0C) or the fixed feature power button that is enabled in the FADT (flag == PWR_BUTTON bit 4). So I don't see how the shutdown is purely an ACPI function. Is there something else to the story? Is it relying on PV tools to do it? Xen (and QEMU seemingly) implement the 'Fixed Power Button' (section 4.8.2.2.1.1 on my spec) and this requires the PWR_BUTTON flag to be clear (according table 4-13). It also does not require a power button device to be implemented (which is presumably why this way of doing it was chosen). which is presumably why this way of doing it was chosen Yea it is simpler plus the power button device would then need a bunch of GPE plumbing to get events. Ross Paul Ross ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel -- Ross Philipson -- Ross Philipson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 05/29/15 10:49, Ian Campbell wrote: On Fri, 2015-05-29 at 15:40 +0100, Jan Beulich wrote: I've mentioned it at least twice now but nobody seems to think it is of note that even with the current settings it does the right thing about 1 time in 10? Is Win7 really expected to behave so randomly here? Perhaps not expected, but then I also don't think we install all the latest bits, but whatever is on the install media? I know I've seen the default action preselected for the user to be different on different instances of native hardware Win7 installs (but of course that could as well have been due to firmware differences, albeit I doubt there's many moder systems around that don't support both S3 and S4). OK, so the gist I'm getting is that it's quite possible that Win7 actually does just roll a d20 and only hibernate on a prime number... I would expect that this is a uninitialized variable path in Win7 on the virtual hardware config (the roll a d20). Since it looks like you can do things in the guest, a better thing would be to force the action to do on the power button press. I just found a web page http://www.pcworld.com/article/225833/Tweak_Your_Windows_PCs_Sleep_Mode.html That says there are BIOS settings that Win7 will also look at. Could be the colo needs some changes also. -Don Slutz Also, when the test fails the guest is also not hibernating either. Would we have ways to tell it at least tried to enter e.g. S3? I'm not sure, but it's not apparent in the screen shot nor in any of the logs (qemu etc), I think I'd expect to see _something_ there? Plus I've queried the impact of change the ACPI s3/s4 settings on the save/restore/migrate tests in the flight more than once and nobody has responded to that either. I have no idea, and hence didn't respond to that part. OK, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
-Original Message-
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: 29 May 2015 14:14
To: Jan Beulich
Cc: Andrew Cooper; Paul Durrant; Ian Jackson; xen-devel
Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-29 at 14:04 +0100, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such
changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
The strange this is that it does work _sometimes_, either by complete
coincidence or because there is something non-deterministic about how
Win7 reacts to this ACPI event.
How long is the test waiting for the OS to shut down though? If you get
unlucky, Windows will wander off to Windows Update, download a bazillion
patches and take more than an hour to shut down. If you’re lucky, it may shut
down in 10 seconds or less.
Paul
Does anyone know which setting we would want to change? In particular it
would be good if I knew what to look for to check the current status...
Jan
-8--
From 2d1b814e65676c3cf56ce2e569491953607f53f7 Mon Sep 17 00:00:00
2001
From: Ian Campbell ian.campb...@citrix.com
Date: Fri, 29 May 2015 13:51:33 +0100
Subject: [PATCH] Turn off acpi_shutdown for windows 7
As described in 1432284841.10746.136.ca...@citrix.com /
http://lists.xen.org/archives/html/xen-devel/2015-05/msg03016.html
Windows 7 does not appear to reliably actually shutdown when asked to
via the ACPI power button.
Once this patch is applied some force pushes will likely be needed in
order for this to not appear as a regression.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Paul Durrant paul.durr...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com,
Cc: Jan Beulich jbeul...@suse.com
---
Alternatively could make it an allowed/non-blocking failure?
---
make-flight | 1 -
1 file changed, 1 deletion(-)
diff --git a/make-flight b/make-flight
index 8a1fceb..5120891 100755
--- a/make-flight
+++ b/make-flight
@@ -206,7 +206,6 @@ do_hvm_win7_x64_tests () {
job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-
win7-amd64 \
test-win xl $xenarch $dom0arch $qemuu_runvar \
win_image=win7-x64.iso \
-win_acpi_shutdown=true \
all_hostflags=$most_hostflags,hvm
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 29/05/15 15:00, Ian Campbell wrote:
On Fri, 2015-05-29 at 14:28 +0100, Jan Beulich wrote:
On 29.05.15 at 15:14, andrew.coop...@citrix.com wrote:
On 29/05/15 14:04, Jan Beulich wrote:
On 29.05.15 at 14:54, ian.campb...@citrix.com wrote:
On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote:
If win7 doesn't shutdown given a power button request I'd be more
inclined to remove the setting in osstest for those flights and let
guest-stop go back to being never pass than to start making such changes
to the VM config which I think would probably break the preceding
suspend and migration tests (which aren't completely reliable, but are
far more so than this shutdown one).
Does anyone have any ideas here or shall I propose:
Unless we have a way to make an adjustment inside the guest for the
power button to gain shutdown meaning, I think there's no alternative
to the change below.
You can avoid advertising S3/S4 in the ACPI tables, which iirc causes
the same alteration to happen.
Hvmloader uses the platform/acpi_s{3,4} booleans to control whether the
relevant SSDTs are exposed.
Which libxl even has settings for. That would perhaps be a better first
try than disabling ACPI shutdown.
I've mentioned it at least twice now but nobody seems to think it is of
note that even with the current settings it does the right thing about 1
time in 10? Is Win7 really expected to behave so randomly here?
Windows is far from bug free, and also a black box. I really cannot
answer whether this is intended behaviour or not.
Also, when the test fails the guest is also not hibernating either.
Plus I've queried the impact of change the ACPI s3/s4 settings on the
save/restore/migrate tests in the flight more than once and nobody has
responded to that either.
save/restore/migrate necessarily need PV drivers inside the guest, and
installing PV drivers should set the sane defaults inside the guest.
What does OSSTest do with PV drivers?
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-29 at 15:25 +0100, Paul Durrant wrote: -Original Message- From: Ian Campbell [mailto:ian.campb...@citrix.com] Sent: 29 May 2015 14:14 To: Jan Beulich Cc: Andrew Cooper; Paul Durrant; Ian Jackson; xen-devel Subject: Re: [Xen-devel] ACPI shutdown unreliable with win7? On Fri, 2015-05-29 at 14:04 +0100, Jan Beulich wrote: On 29.05.15 at 14:54, ian.campb...@citrix.com wrote: On Fri, 2015-05-22 at 10:08 +0100, Ian Campbell wrote: If win7 doesn't shutdown given a power button request I'd be more inclined to remove the setting in osstest for those flights and let guest-stop go back to being never pass than to start making such changes to the VM config which I think would probably break the preceding suspend and migration tests (which aren't completely reliable, but are far more so than this shutdown one). Does anyone have any ideas here or shall I propose: Unless we have a way to make an adjustment inside the guest for the power button to gain shutdown meaning, I think there's no alternative to the change below. The strange this is that it does work _sometimes_, either by complete coincidence or because there is something non-deterministic about how Win7 reacts to this ACPI event. How long is the test waiting for the OS to shut down though? If you get unlucky, Windows will wander off to Windows Update, download a bazillion patches and take more than an hour to shut down. If you’re lucky, it may shut down in 10 seconds or less. The screenshot in e.g. http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64-amd64-xl-qemut-win7-amd64/info.html seems to show that the guest isn't even trying to shut down, it's just sat there at the desktop: http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64-amd64-xl-qemut-win7-amd64/win.guest.osstest--vnc.jpeg I think if it had hit WU there would be activity on the screen? FWIW We appear to wait 200s, if we were seeing failures due to windows update then I'd be inclined to extend that, but I think right now that would be premature, unless WU happens with no status on the screen. Ian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] ACPI shutdown unreliable with win7?
In osstest self gate flight 56412 a change to make HVM guests configurably use xl shutdown -F (-F == use ACPI fallback if PV drivers absent) and apply the option to the win7 and winxpsp3 tests went into production. On winxpsp3 this appears to have been a success and things are working pretty well since that flight: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3-vcpus1.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3-vcpus1.html However win7 seems to be in somewhat poorer shape: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-win7-amd64.html it passes less than one time in 10 (of the ones which don't get blocked earlier on). The problem seems to be independent of the qemu version and with qemuu of seabios vs rombios. dom0 kernel also seems irrelevant. Some random examples which I looked at: http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64-amd64-xl-qemut-win7-amd64/info.html http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64-i386-xl-qemuu-win7-amd64/info.html http://logs.test-lab.xenproject.org/osstest/logs/56718/test-amd64-amd64-xl-qemut-win7-amd64/info.html all showed in there vnc screenshot a guest which is showing no indication of shutting down. Looking a bit closer at the first 56929 one xl list shows the windows domain 18 in state blocked. The host serial log shows an apparently successful restore into dom18, then the debug key output after failure show CPU1, corresponding to d18v0, sat in hvm_io_pending: May 22 01:27:58.889074 (XEN) *** Dumping CPU1 host state: *** May 22 01:27:58.897025 (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] May 22 01:27:58.904993 (XEN) CPU:1 May 22 01:27:58.905036 (XEN) RIP:e008:[82d0801bdce5] hvm_io_pending+0/0x52 May 22 01:27:58.912996 (XEN) RFLAGS: 0297 CONTEXT: hypervisor (d18v0) May 22 01:27:58.913056 (XEN) rax: rbx: 8300cceeb000 rcx: fed000f0 May 22 01:27:58.920996 (XEN) rdx: 0004 rsi: fed000f4 rdi: 8300cceeb000 May 22 01:27:58.928997 (XEN) rbp: 83022b4bf5b8 rsp: 83022b4bf520 r8: 0001 May 22 01:27:58.936987 (XEN) r9: r10: r11: f8b9c9e8 May 22 01:27:58.944986 (XEN) r12: 830219db5000 r13: 0004 r14: 82e0024433a0 May 22 01:27:58.953029 (XEN) r15: cr0: 80050033 cr4: 001526f0 May 22 01:27:58.960994 (XEN) cr3: 00010c38e000 cr2: f8a0007d1538 May 22 01:27:58.968987 (XEN) ds: es: fs: gs: ss: cs: e008 May 22 01:27:58.969027 (XEN) Xen stack trace from rsp=83022b4bf520: May 22 01:27:58.976990 (XEN)82d0801b8300 0001 83022b4bfb60 83022b4bf628 May 22 01:27:58.985003 (XEN)00010002 fed000f0 0101 83022b4bf578 May 22 01:27:58.993017 (XEN)801b8d1c fed000f0 0004 May 22 01:27:59.001010 (XEN)0120 83022b4bf630 0004 0004 May 22 01:27:59.009040 (XEN)00f0 83022b4bf9a8 0002 83022b4bf5d8 May 22 01:27:59.017016 (XEN)82d0801b85fb 8302 83022b4bf9a8 83022b4bf668 May 22 01:27:59.025011 (XEN)82d0801b9086 83022b4bf9a8 82d0801b85fb 8302 May 22 01:27:59.033009 (XEN)00022900 83022b4bfb60 83f4 83022b4bf978 May 22 01:27:59.040990 (XEN)fed000f0 0001 ffd090f0 83022b4bf688 May 22 01:27:59.041030 (XEN)008b 82d08028d900 May 22 01:27:59.048993 (XEN)83022b4bfb60 83022b4bf678 82d0801b92b8 83022b4bf688 May 22 01:27:59.057007 (XEN)82d0801958de 83022b4bfac8 82d080197875 83022b4bf6c8 May 22 01:27:59.064999 (XEN)82d0801f7b1c 83012c9ea008 0001 0080 May 22 01:27:59.073007 (XEN)01d9
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 22.05.15 at 10:54, ian.campb...@citrix.com wrote:
May 22 01:28:33.149028 (XEN) VCPU information and callbacks for
domain 18:
May 22 01:28:33.156972 (XEN) VCPU0: CPU2 [has=F] poll=0
upcall_pend=00 upcall_mask=00 dirty_cpus={2}
May 22 01:28:33.165038 (XEN) cpu_hard_affinity={0-47}
cpu_soft_affinity={0-3}
May 22 01:28:33.173029 (XEN) pause_count=0 pause_flags=1
May 22 01:28:33.173064 (XEN) paging assistance: hap, 4 levels
May 22 01:28:33.181020 (XEN) No periodic timer
May 22 01:28:33.181052 (XEN) VCPU1: CPU1 [has=F] poll=0
upcall_pend=00 upcall_mask=00 dirty_cpus={1}
May 22 01:28:33.189031 (XEN) cpu_hard_affinity={0-47}
cpu_soft_affinity={0-3}
May 22 01:28:33.197069 (XEN) pause_count=0 pause_flags=1
May 22 01:28:33.197105 (XEN) paging assistance: hap, 4 levels
May 22 01:28:33.205013 (XEN) No periodic timer
At least this last part certainly isn't the same as in e.g. flight 56898,
where pause_flags=0 for both guest vCPU-s.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 22/05/15 09:54, Ian Campbell wrote: In osstest self gate flight 56412 a change to make HVM guests configurably use xl shutdown -F (-F == use ACPI fallback if PV drivers absent) and apply the option to the win7 and winxpsp3 tests went into production. On winxpsp3 this appears to have been a success and things are working pretty well since that flight: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3-vcpus1.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3-vcpus1.html However win7 seems to be in somewhat poorer shape: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-win7-amd64.html it passes less than one time in 10 (of the ones which don't get blocked earlier on). The problem seems to be independent of the qemu version and with qemuu of seabios vs rombios. dom0 kernel also seems irrelevant. This is because there is no such thing as ACPI shutdown. There is ACPI Someone pressed the power button and ACPI Someone closed the laptop lid. I believe Win7 attempts to sleep by default, rather than to shut down, although IIRC this does depend on which S states are offered in the ACPI tables. One thing to try would be to boot windows without any S3 or S4 SSDT tables, which should persuade windows into believing that someone pressed the power button should mean S5 shutdown. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-22 at 09:59 +0100, Andrew Cooper wrote: On 22/05/15 09:54, Ian Campbell wrote: In osstest self gate flight 56412 a change to make HVM guests configurably use xl shutdown -F (-F == use ACPI fallback if PV drivers absent) and apply the option to the win7 and winxpsp3 tests went into production. On winxpsp3 this appears to have been a success and things are working pretty well since that flight: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3-vcpus1.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3-vcpus1.html However win7 seems to be in somewhat poorer shape: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-win7-amd64.html it passes less than one time in 10 (of the ones which don't get blocked earlier on). The problem seems to be independent of the qemu version and with qemuu of seabios vs rombios. dom0 kernel also seems irrelevant. This is because there is no such thing as ACPI shutdown. There is ACPI Someone pressed the power button and ACPI Someone closed the laptop lid. Understood, however this did work in my manual testing and does occasionally pass. e.g. in http://logs.test-lab.xenproject.org/osstest/logs/56759/test-amd64-amd64-xl-qemut-win7-amd64/info.html which was successful the qemu log shows: shutdown requested in cpu_handle_ioreq Issued domain 18 poweroff Log-dirty: no command yet. In the failure cases there is no indication in the logs or screenshots that windows is either hibernating or shutting down, or doing anything else at all. I believe Win7 attempts to sleep by default, rather than to shut down, although IIRC this does depend on which S states are offered in the ACPI tables. osstest ought to be providing the exact same thing each time, so unless there is some non-determinism in win7's logic (I would hope not) I think it ought to be making the same choice each time. One thing to try would be to boot windows without any S3 or S4 SSDT tables, which should persuade windows into believing that someone pressed the power button should mean S5 shutdown. If win7 doesn't shutdown given a power button request I'd be more inclined to remove the setting in osstest for those flights and let guest-stop go back to being never pass than to start making such changes to the VM config which I think would probably break the preceding suspend and migration tests (which aren't completely reliable, but are far more so than this shutdown one). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
