KVM_EXIT_HALT and KVM_CREATE_IRQCHIP

KVM_EXIT_HALT and KVM_CREATE_IRQCHIP

[Pekka Enberg]

Hi!

How is the guest supposed to halt the hypervisor if KVM_CREATE_IRQCHIP 
is being used? The kvm_emulate_halt() function seems to handle the halt 
event completely if irqchip_in_kernel() returns true and thus never 
exits to the hypervisor.

I see there's a KVM_GET_MP_STATE ioctl that can be used to check if 
state is KVM_MP_STATE_HALTED but as we never exit to the hypervisor, how 
is this supposed to work? Am I missing something obvious here?

			Pekka

Re: KVM_EXIT_HALT and KVM_CREATE_IRQCHIP

[Avi Kivity]

On 06/10/2010 12:52 PM, Pekka Enberg wrote:

>
> How is the guest supposed to halt the hypervisor if KVM_CREATE_IRQCHIP 
> is being used? The kvm_emulate_halt() function seems to handle the 
> halt event completely if irqchip_in_kernel() returns true and thus 
> never exits to the hypervisor.

"The hypervisor" is the combination of userspace and kvm.  Without 
KVM_CREATE_IRQCHIP, HLT is emulated in userspace.  With 
KVM_CREATE_IRQCHIP, HLT is emulated in the kernel.  Emulating HLT in the 
kernel results in a faster return from HLT, which occurs frequently.

If you need to break out of the kernel, send a signal to the thread 
that's running the vcpu.  That works whether the guest is running or 
sleeping.

> I see there's a KVM_GET_MP_STATE ioctl that can be used to check if 
> state is KVM_MP_STATE_HALTED but as we never exit to the hypervisor, 
> how is this supposed to work? Am I missing something obvious here?

In general you only rarely want to check the state (example are for 
debugging and for live migration).  It's not a stable value (the guest 
executing HLT, or a guest interrupt delivered, will change its value).  
What's your use case?

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

Re: KVM_EXIT_HALT and KVM_CREATE_IRQCHIP

[Pekka Enberg]

Hi Avi,

On 06/10/2010 12:52 PM, Pekka Enberg wrote:
>> How is the guest supposed to halt the hypervisor if KVM_CREATE_IRQCHIP
>> is being used? The kvm_emulate_halt() function seems to handle the
>> halt event completely if irqchip_in_kernel() returns true and thus
>> never exits to the hypervisor.

On 6/10/10 1:03 PM, Avi Kivity wrote:
> "The hypervisor" is the combination of userspace and kvm. Without
> KVM_CREATE_IRQCHIP, HLT is emulated in userspace. With
> KVM_CREATE_IRQCHIP, HLT is emulated in the kernel. Emulating HLT in the
> kernel results in a faster return from HLT, which occurs frequently.
>
> If you need to break out of the kernel, send a signal to the thread
> that's running the vcpu. That works whether the guest is running or
> sleeping.

OK, makes sense.

On 06/10/2010 12:52 PM, Pekka Enberg wrote:
>> I see there's a KVM_GET_MP_STATE ioctl that can be used to check if
>> state is KVM_MP_STATE_HALTED but as we never exit to the hypervisor,
>> how is this supposed to work? Am I missing something obvious here?

On 6/10/10 1:03 PM, Avi Kivity wrote:
> In general you only rarely want to check the state (example are for
> debugging and for live migration). It's not a stable value (the guest
> executing HLT, or a guest interrupt delivered, will change its value).
> What's your use case?

Well, power off, basically. Specifically, running a small test 'kernel' 
that exists after it's done its work. I guess the thing I was missing 
was that hlt is really for other purposes than power off. I guess it's 
up to the hypervisor to emulate APM or something and stop the hypervisor 
there?

			Pekka

Re: KVM_EXIT_HALT and KVM_CREATE_IRQCHIP

[Avi Kivity]

On 06/10/2010 01:15 PM, Pekka Enberg wrote:
>
> On 06/10/2010 12:52 PM, Pekka Enberg wrote:
>>> I see there's a KVM_GET_MP_STATE ioctl that can be used to check if
>>> state is KVM_MP_STATE_HALTED but as we never exit to the hypervisor,
>>> how is this supposed to work? Am I missing something obvious here?
>
> On 6/10/10 1:03 PM, Avi Kivity wrote:
>> In general you only rarely want to check the state (example are for
>> debugging and for live migration). It's not a stable value (the guest
>> executing HLT, or a guest interrupt delivered, will change its value).
>> What's your use case?
>
> Well, power off, basically. Specifically, running a small test 
> 'kernel' that exists after it's done its work. I guess the thing I was 
> missing was that hlt is really for other purposes than power off. I 
> guess it's up to the hypervisor to emulate APM or something and stop 
> the hypervisor there?
>

HLT has nothing to do with power off.  Qemu emulates ACPI power 
management, you can either do that or roll your own (for example an I/O 
port that calls exit(0) when the guest accesses it).

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