This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Avi Kivity <avi@xxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 2 Nov 2009 07:28:21 -0800 (PST)
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, Glauber Costa <glommer@xxxxxxxxxx>, maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, the, Ingo Molnar <mingo@xxxxxxxxxx>, zach.brown@xxxxxxxxxx, chris.mason@xxxxxxxxxx
Delivery-date: Mon, 02 Nov 2009 07:30:08 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AED54D1.6070706@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> 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.

> 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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>