Re: [RFC PATCH 14/17] kvm: add a reset capability

[Gregory Haskins <ghaskins@novell.com>]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

Avi Kivity wrote:
> Gregory Haskins wrote:
>> Avi Kivity wrote:
>>  
>>> Gregory Haskins wrote:
>>>    
>>>> We need a way to detect if a VM is reset later in the series, so lets
>>>> add a capability for userspace to signal a VM reset down to the
>>>> kernel.
>>>>         
>>> How do you handle the case of a guest calling kexec to load a new
>>> kernel?  Or is that not important for your use case?
>>>
>>>     
>>
>> Hmm..I had not considered this.  Any suggestions on ways to detect it?
>>
>>   
>
> Best would be not to detect it; it's tying global events into a
> device.  Instead, have a reset command for your device and have the
> driver issue it on load and unload.

Yes, good point.  This is doable within the existing infrastructure, but
it would have to be declared in each devices ABI definition.  I could
make it more formal and add it to the list of low-level bus-verbs, like
DEVICEOPEN, DEVICECLOSE, etc.

>
> btw, reset itself would be better controlled from userspace; qemu
> knows about resets and can reset vbus devices directly instead of
> relying on kvm to reset them.
In a way, this is what I have done (note to self: post the userspace
patches)

The detection is done by userspace, and it invokes an ioctl.  The kernel
based devices then react if they are interested.  In my case, vbus
registers for reset-notification, and it acts as if the guest exited
when it gets reset (e.g. it issues DEVICECLOSE verbs to all devices the
guest had open).



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]