Re: [PATCH 10/10] x86, ACPI: default to reboot via ACPI (again)

Avi Kivity
2008-11-10T08:55:08Z

Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> wrote:
>
>
>> Avi Kivity wrote:
>>
>>> I think the sequence should be acpi -> kbd -> triple fault. Given that
>>> Windows uses ACPI, the number of machines that support it is much larger
>>> (and growing daily) than the number of machines that do not.
>>>
>>>
>> Like with many other things ACPI, there probably should be an ACPI
>> date cutoff for using it by default. There is also port CF9 reboot
>> (often incorrectly described as "PCI reboot", but it has nothing to
>> do with the PCI standard.)
>>
>
> so, the sequence should be:
>
> [ acpi if date > 2007 ] -> kbd -> triple fault
>
>

2007? Maybe 2002, a year after Windows XP was launched?

Windows XP uses ACPI by default. Not sure about reboot, but I wouldn't
be surprised if it did, since it's such a simple feature, not involving
AML etc.

> Where in this sequence should we insert port-CF9 reboot? We have no
> discovery of it, etc. The KGDB reboot will do _something_ on most
> boxes, so inserting it like this:
>
> [ acpi if date > 2007 ] -> kbd -> port-CF9 -> triple fault
>

Most likely ACPI uses port CF9 if it's available.

> ... will likely have no practical impact as we rarely get to the
> triple fault method to begin with. So the reboot chain we'd like to
> have is:
>
> [ acpi if date > 2007 ] -> safe-port-CF9 -> kbd -> triple fault
>
> ... where safe-port-CF9 is something that can be done safely on all
> x86 boxes.
>
> Anyway, safe-port-CF9 aside, the ACPI sequence should definitely be
> cutoff based, so the plain re-introduction of the patch that changes
> the default is not acceptable.
>

What the vmx issues showed us is that keyboard reset is unreliable on
some machines, so reset was actually done by triple-fault, which doesn't
work well when vmx is enabled (if it's connected to INIT; note it won't
reset peripherals in that case).

--
error compiling committee.c: too many arguments to function