Re: [Xen-devel] [PATCH] shut down domain when last vCPU goes down

[Juergen Gross <jgross@xxxxxxxx>]

On 16/02/18 17:25, Jan Beulich wrote:
>>>> On 16.02.18 at 16:52, <roger.pau@xxxxxxxxxx> wrote:
>> On Fri, Feb 16, 2018 at 08:10:48AM -0700, Jan Beulich wrote:
>>> I've just had to deal with an early boot crash of Linux which occurred
>>> so early that even "earlyprintk=xen" did not produce any useful output.
>>> Hence the domain appeared to hang, while in fact it had brought down its
>>> only vCPU. By translating this to a shutdown, the situation will be
>>> better recognizable.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>
>> I'm wondering, is it common for a domain to shutdown by shutting down
>> all it's vCPUs?
>>
>> In the scenario that you describe above it seems it would be more
>> helpful to issue a SHUTDOWN_crash instead maybe with a gdprintk
>> message in order to aid debugging.
> 
> Seeing this I was puzzled too; I have no idea why Linux does this,
> other than this being an attempt to provide a PV equivalent of the
> HLT instruction. But no, SHUTDOWN_crash is not appropriate imo
> (and I did consider it) - we can't know what the reason was for the
> guest to issue the hypercall; in particular we shouldn't trigger
> actions (like dumping) that are likely tied to a crash unless we're
> sure there was a crash.

Linux does this in case of hitting an exception before the common trap
handling is set up. It just is using halt() which will issue the hlt
instruction on bare metal and is calling VCPU_down in a pv guest when
interrupts are off. In case the console would have been set up already
you would have seen registers printed.

What could be done is using an early pv-op for the hlt instruction
translating to SHUTDOWN_crash in case of interrupts off and switching
to the current variant when trap handling has been initialized.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel