| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home