Re: Early ACPI events prevent subsequent ACPI functionality on xen 4.3 + HVM domU

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, May 21, 2013 at 04:51:29PM +0100, George Dunlap wrote:
> On 05/21/2013 04:36 PM, George Dunlap wrote:
> >On 05/21/2013 04:17 PM, Alex Bligh wrote:
> >>
> >>
> >>--On 21 May 2013 15:34:34 +0100 George Dunlap
> >><george.dunlap@eu.citrix.com> wrote:
> >>
> >>>But the problem actually has nothing to do with ACPI -- it's the PV
> >>>shutdown command that is getting lost after the driver registers
> >>>HVM_PARAM_CALLBACK_IRQ but before something else comes up that starts
> >>>watching ../control/shutdown.
> >>
> >>I'm puzzled as to why you say that as the problem does not appear
> >>without ACPI in the xl.conf file.
> >
> >I can still get the same effect -- the only difference for me seems to
> >be that the "window" in which I can send a shutdown with no effect it is
> >shorter.  Maybe ACPI causes the extra few seconds at boot which makes it
> >more likely you're going to hit it?
> 
> If you can't trigger it manually, try something like this:
> 
> xl create dom.cfg ; while ! xl shutdown dom ; do sleep 1 ; done
> 
> Before PARAM_CALLBACK_IRQ is set, "xl shutdown dom" will fail, so
> this will keep trying every 1 second until it succeeds.  Since this
> is most likely within 1 second of PARAM_CALLBACK_IRQ being set, it
> should be within the window where the watch isn't set yet (or
> whatever it is that makes domU responsive to the PV shutdown
> commands).
> 
> It works reliably for me with acpi=0.

And with 'acpi=1' ?

>From the Linux side, there are three paths that can cause a shutdown.
Internally the user can invoke poweroff, which will end up calling the
shutdown procecedure.

PV path - which works on both PVHVM and PV. This is triggered by
watch firring on control/shutdown. Thought interestingly if you wrote
the initial value of "poweroff" there, the kernel would not read it unless
a trigger followed. A change can be done in there to read the value
at bootup and see if "poweroff" is present.

And the emulated path. I think this is ACPI S5, but I would have to
dig a bit in the QEMU to see if that is how it does it. This is the
same path that Windows or any HVM guests would shutdown.

For the emulated path I am not entirely sure how the ACPI path works 
when a guest hasn't initialized its ACPI machinery. I would think the
ACPI SCI would be triggered, but it might not be since the ACPI AML
has no way of running (as the OS hasn't even started reading it). In
which case the emulated path ought to use a fallback, whatever that is.
But I am not sure if there is a fallback except "yanking the power" - which
I think is what normal machines do if you hold the power off button for
more than 3 seconds.