Avi Kivity wrote:
>>>
>>>
>> For a graceful reboot, this one is not needed since every APs are
>> already brought to HALT status before BSP issue RESET signal. But in
>> case of non-graceful reboot, it is possible the VCPUs are still
>> executing guest instruction, so we kick the VCPU and then use this logic
>> to force the exception handler to be a heavy VM Exit and execute
>> following code at beginning of kvm_vcpu_ioctl_run. (Let
>> VCPU_MP_STATE_UNINITIALIZED take effective)
>>
>> if (unlikely(vcpu->mp_state == VCPU_MP_STATE_UNINITIALIZED)) {
>> if (irqchip_in_kernel(vcpu->kvm) && vcpu->apic)
>> kvm_lapic_reset(vcpu);
>> kvm_vcpu_block(vcpu);
>> vcpu_put(vcpu);
>> return -EAGAIN;
>> }
>>
>> Whether we need to handle those un-graceful reboot case is up to you :-)
>> If not, then those code can be removed.
>>
>>
>
> We do need to support ungraceful resets. But this could easily be done
> via vcpu->requests.
>
> To reset a vcpu:
>
> set_bit(KVM_REQ_RESET, &vcpu->requests)
> kvm_vcpu_kick(vcpu);
>
> And in __vcpu_run():
>
> if (vcpu_requests) {
> if (test_and_reset_bit(KVM_REQ_RESET, &vcpu->requests))
> ....
> }
>
>
To be clear, you can move the reset call to that location ("...") and
avoid the need to take a heavyweight exit completely.
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
