Thread (50 messages) flat view 50 messages, 8 authors, 2009-04-05

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

From: Gregory Haskins <hidden>
Date: 2009-03-31 20:35:54
Also in: kvm, lkml

Avi Kivity wrote:
Gregory Haskins wrote:
quoted
Avi Kivity wrote:
 
quoted
Gregory Haskins wrote:
   
quoted
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).

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help