Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation

[Avi Kivity <avi@xxxxxxxxxx>]

On 11/02/2009 05:28 PM, Dan Magenheimer wrote:
> > From: Avi Kivity [mailto:avi@xxxxxxxxxx]
> >
> > On 10/29/2009 06:15 PM, Dan Magenheimer wrote:
> >      
> > > On a related note, though some topic drift, many of
> > > the problems that occur in virtualization due to migration
> > > could be better addressed if Linux had an architected
> > > interface to allow it to be signaled if a migration
> > > occurred, and if Linux could signal applications of
> > > the same.  I don't have any cycles (pun intended) to
> > > think about this right now, but if anyone else starts
> > > looking at it, I'd love to be cc'ed.
> > >        
> > IMO that's not a good direction.  The hypervisor should not depend on
> > the guest for migration (the guest may be broken, or
> > malicious, or being
> > debugged, or slow).  So the notification must be asynchronous, which
> > means that it will only be delivered to applications after
> > migration has
> > completed.
> >      
> I definitely agree that the hypervisor can't wait for a guest
> to respond.
>
> You've likely thought through this a lot more than I have,
> but I was thinking that if the kernel received the notification
> as some form of interrupt, it could determine immediately
> if any running threads had registered for "SIG_MIGRATE"
> and deliver the signal synchronously.
>    
Interrupts cannot be delivered immediately.  Exceptions can, but not all 
guest code is prepared to handle them.  Once you start to handle the 
exception, migration is complete and you are late.

> > Instead of a "migration has occured, run for the hills" signal we're
> > better of finding out why applications want to know about
> > this event and
> > addressing specific needs.
> >      
> Perhaps.  It certainly isn't warranted for this one
> special case of timestamp handling.  But I'll bet 5-10 years
> from now, after we've handled a few special cases, we'll
> wish that we would have handled it more generically.
>    
Or we'll find that backwards compatibility for the generic signal is 
killing some optimization.
--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel