From: Matthew Garrett <mjg@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
Eduardo Habkost <ehabkost@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Zhao Yakui <yakui.zhao@intel.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Ingo Molnar <mingo@elte.hu>, Andrey Borzenkov <arvidjaar@mail.ru>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 15/15] Revert "x86: default to reboot via ACPI"
Date: Sun, 9 Nov 2008 10:24:23 +0000 [thread overview]
Message-ID: <20081109102423.GA13217@srcf.ucam.org> (raw)
In-Reply-To: <4916B737.7050107@redhat.com>
On Sun, Nov 09, 2008 at 12:11:03PM +0200, Avi Kivity wrote:
> Matthew Garrett wrote:
> >Hmm. But we're seeing some machines that end up very confused if
> >rebooted via ACPI. I guess we need to run Vista on them to find out how
> >they behave. What OSI strings did your KVM setup expose? We know that
> >Windows changes behaviour under various circumstances depending on which
> >OS the firmware requests, so it's almost possible that this is another
> >of those cases.
> >
>
> Isn't it the other way around? The firmware changes behavior depending
> on how the OS identifies itself?
That also happens, yes.
> Reboot is a fixed feature IIRC, so it cannot change depending on
> identification strings.
The ID strings that the firmware requests give a good idea about which
operating systems the machine has been tested with. If Vista uses the
ACPI method then having the firmware request the OSI string for Vista
gives us a good indication that it's safe to use the ACPI method.
--
Matthew Garrett | mjg59@srcf.ucam.org
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Garrett <mjg@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Zhao Yakui <yakui.zhao@intel.com>, Len Brown <lenb@kernel.org>,
Andrey Borzenkov <arvidjaar@mail.ru>, Ingo Molnar <mingo@elte.hu>,
Eduardo Habkost <ehabkost@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@osdl.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 15/15] Revert "x86: default to reboot via ACPI"
Date: Sun, 9 Nov 2008 10:24:23 +0000 [thread overview]
Message-ID: <20081109102423.GA13217@srcf.ucam.org> (raw)
In-Reply-To: <4916B737.7050107@redhat.com>
On Sun, Nov 09, 2008 at 12:11:03PM +0200, Avi Kivity wrote:
> Matthew Garrett wrote:
> >Hmm. But we're seeing some machines that end up very confused if
> >rebooted via ACPI. I guess we need to run Vista on them to find out how
> >they behave. What OSI strings did your KVM setup expose? We know that
> >Windows changes behaviour under various circumstances depending on which
> >OS the firmware requests, so it's almost possible that this is another
> >of those cases.
> >
>
> Isn't it the other way around? The firmware changes behavior depending
> on how the OS identifies itself?
That also happens, yes.
> Reboot is a fixed feature IIRC, so it cannot change depending on
> identification strings.
The ID strings that the firmware requests give a good idea about which
operating systems the machine has been tested with. If Vista uses the
ACPI method then having the firmware request the OSI string for Vista
gives us a good indication that it's safe to use the ACPI method.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2008-11-09 10:25 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-05 19:56 [PATCH 00/15] x86: disable virt on kdump and emergency_restart (v2) Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 01/15] x86 kdump: Extract kdump-specific code from crash_nmi_callback() Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 02/15] x86 kdump: Move crashing_cpu assignment to nmi_shootdown_cpus() Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 03/15] x86 kdump: Create kdump_nmi_shootdown_cpus() Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 04/15] x86 kdump: Make kdump_nmi_callback() a function ptr on crash_nmi_callback() Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 05/15] x86 kdump: Make nmi_shootdown_cpus() non-static Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 06/15] x86: Move nmi_shootdown_cpus() to reboot.c Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 07/15] x86: Make nmi_shootdown_cpus() available on !SMP and !X86_LOCAL_APIC Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 08/15] x86: Disable IRQs before doing anything on nmi_shootdown_cpus() Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 09/15] x86: Emergency virtualization disable function Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 22:27 ` Pavel Machek
2008-11-05 22:27 ` Pavel Machek
2008-11-06 15:34 ` Eduardo Habkost
2008-11-06 15:34 ` Eduardo Habkost
2008-11-06 15:34 ` Eduardo Habkost
2008-11-06 18:11 ` Pavel Machek
2008-11-06 18:11 ` Pavel Machek
2008-11-05 19:56 ` [PATCH 10/15] kdump: Hook emergency_virt_disable() on crash shutdown code Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 11/15] x86: disable virtualization on all CPUs if needed, on emergency_restart Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 12/15] kvm: svm: no-parameters version of svm_hardware_disable() Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 13/15] kvm: svm: register virt_disable function on hardware_setup Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 14/15] kvm: vmx: crash_hardware_disable function Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` [PATCH 15/15] Revert "x86: default to reboot via ACPI" Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-05 19:56 ` Eduardo Habkost
2008-11-06 7:14 ` Ingo Molnar
2008-11-06 7:14 ` Ingo Molnar
2008-11-06 7:14 ` Ingo Molnar
2008-11-06 12:40 ` Eduardo Habkost
2008-11-06 12:40 ` Eduardo Habkost
2008-11-06 12:40 ` Eduardo Habkost
2008-11-06 14:30 ` Ingo Molnar
2008-11-06 14:30 ` Ingo Molnar
2008-11-06 14:30 ` Ingo Molnar
2008-11-06 15:06 ` Ingo Molnar
2008-11-06 15:06 ` Ingo Molnar
2008-11-06 15:06 ` Ingo Molnar
2008-11-06 15:41 ` Eric W. Biederman
2008-11-06 15:41 ` Eric W. Biederman
2008-11-06 15:52 ` Avi Kivity
2008-11-06 15:52 ` Avi Kivity
2008-11-06 15:52 ` Avi Kivity
2008-11-06 15:53 ` Andrey Borzenkov
2008-11-06 15:53 ` Andrey Borzenkov
2008-11-06 19:50 ` Len Brown
2008-11-06 19:50 ` Len Brown
2008-11-06 21:50 ` Matthew Garrett
2008-11-06 21:50 ` Matthew Garrett
2008-11-06 22:17 ` Len Brown
2008-11-06 22:17 ` Len Brown
2008-11-06 22:17 ` Len Brown
2008-11-06 23:24 ` Matthew Garrett
2008-11-06 23:24 ` Matthew Garrett
2008-11-07 1:01 ` Zhao Yakui
2008-11-07 1:01 ` Zhao Yakui
2008-11-07 0:59 ` Matthew Garrett
2008-11-07 0:59 ` Matthew Garrett
2008-11-07 0:59 ` Matthew Garrett
2008-11-09 10:11 ` Avi Kivity
2008-11-09 10:11 ` Avi Kivity
2008-11-09 10:11 ` Avi Kivity
2008-11-09 10:24 ` Matthew Garrett [this message]
2008-11-09 10:24 ` Matthew Garrett
[not found] <fa.UVpnVba3yRAWG3rGZ0sk20JE9hs@ifi.uio.no>
[not found] ` <fa.FPBNKx3BSvZHPZ+eXD4Tb+fuRYk@ifi.uio.no>
[not found] ` <fa.PvVEuEo+f/t4sLmcGyN2Tsl8zYg@ifi.uio.no>
[not found] ` <fa.zzFdOXisTZzBaE1+ueGIYmt+Z5c@ifi.uio.no>
[not found] ` <fa.vQ6HVRcPFFr1zpcXFFOjEPtDdNk@ifi.uio.no>
[not found] ` <fa.ckUqcrtVKbxAkjNggIdajBTHr9Q@ifi.uio.no>
2008-11-07 1:30 ` Robert Hancock
2008-11-07 1:30 ` Robert Hancock
2008-11-07 1:30 ` Robert Hancock
2008-11-07 1:43 ` Matthew Garrett
2008-11-07 1:43 ` Matthew Garrett
2008-11-07 1:43 ` Matthew Garrett
2008-11-07 1:53 ` Len Brown
2008-11-07 1:53 ` Len Brown
2008-11-08 22:32 ` Rafael J. Wysocki
2008-11-08 22:32 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081109102423.GA13217@srcf.ucam.org \
--to=mjg@redhat.com \
--cc=akpm@osdl.org \
--cc=arvidjaar@mail.ru \
--cc=avi@redhat.com \
--cc=ebiederm@xmission.com \
--cc=ehabkost@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=yakui.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.