On 09.03.2010, at 14:19, Avi Kivity wrote:
> On 03/09/2010 03:12 PM, Alexander Graf wrote:
>> On 09.03.2010, at 14:11, Avi Kivity wrote:
>>
>>
>>> On 03/09/2010 03:04 PM, Alexander Graf wrote:
>>>
>>>>
>>>>>> + /* KVM_EXIT_OSI */
>>>>>> + struct {
>>>>>> + __u64 gprs[32];
>>>>>> + } osi;
>>>>>> +
>>>>>> +MOL uses a special hypercall interface it calls 'OSI'. To enable it, we catch
>>>>>> +hypercalls and exit with this exit struct that contains all the guest gprs.
>>>>>> +
>>>>>> +If exit_reason is KVM_EXIT_OSI, then the vcpu has triggered such a hypercall.
>>>>>> +Userspace can now handle the hypercall and when it's done modify the gprs as
>>>>>> +necessary. Upon guest entry all guest GPRs will then be replaced by the values
>>>>>> +in this struct.
>>>>>> +
>>>>>>
>>>>>>
>>>>>>
>>>>> That's migration unsafe. There may not be next guest entry on this host.
>>>>>
>>>>>
>>>> It's as unsafe as MMIO then.
>>>>
>>>>
>>>>
>>> From api.txt:
>>>
>>>
>>>> NOTE: For KVM_EXIT_IO and KVM_EXIT_MMIO, the corresponding operations
>>>> are complete (and guest state is consistent) only after userspace has
>>>> re-entered the kernel with KVM_RUN. The kernel side will first finish
>>>> incomplete operations and then check for pending signals. Userspace
>>>> can re-enter the guest with an unmasked signal pending to complete
>>>> pending operations.
>>>>
>>>
>> Alright - so I add KVM_EXIT_OSI there and be good? :)
>>
>
> Sure, just verify that the note holds for that case too.
The handling of the hypercall write-back is in the same region as the mmio one. So whatever applies for MMIO entries applies for OSI entries too.
Alex--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
