[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to initiate power-off in quest with new microvm machine type

From: Sergio Lopez
Subject: Re: How to initiate power-off in quest with new microvm machine type
Date: Tue, 12 Nov 2019 17:13:33 +0100
User-agent: mu4e 1.2.0; emacs 26.2

Paolo Bonzini <address@hidden> writes:

> On 12/11/19 16:48, Sergio Lopez wrote:
>> Peter Maydell <address@hidden> writes:
>>> On Tue, 12 Nov 2019 at 15:22, Waldek Kozaczuk <address@hidden> wrote:
>>>> Hi,
>>>> I am referring to the machine type described here - 
>>>> https://github.com/qemu/qemu/blob/master/docs/microvm.rst. I would like to 
>>>> know how to initiate power-off sequence from a guest given that ACPI is 
>>>> not available. On firecracker the only way is generating Ctrl-Alt-Del 
>>>> keyboard event by writing proper value to the keyboard controller port 
>>>> 0xfe like so:
>>>> outb(0x64, 0xfe);
>>>> What is the corresponding mechanism on QEMU with microvm machine?
>> To shut down the VM from the guest I can think of two options (that we
>> should probably add to the documentation):
>>  1. Add "-no-reboot" to the QEMU command line (you'd also need this for
>>  the keyboard based method) and trigger a triple fault. If you're
>>  running Linux, you can make this the default by passing "reboot=t" to
>>  the kernel command line.
>>  2. Add an isa-debug-exit device and write to its port in a similar way
>>  you do with the keyboard. There's no need for adding "-no-reboot" to
>>  the command line, as this will cause QEMU to exit immediately.
>> That said, we can easily add a knob for attaching a i8042 keyboard to
>> the microvm machine type. I'm not entirely convinced that this is really
>> necessary, but if it makes people's life easier, it may be worth it.
> I think we should rather add a minimal i8042 device that can only do
> reset (but wouldn't be detected as i8042 by the guest).  But if reboot=t
> works, we could also add it to the automatically-generated command line.

It works even without "reboot=t", but it takes ~5 seconds because Linux
tries other mechanism first.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]