| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
|
To: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation |
|
From: |
Avi Kivity <avi@xxxxxxxxxx> |
|
Date: |
Mon, 02 Nov 2009 17:41:28 +0200 |
|
Cc: |
Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, Glauber Costa <glommer@xxxxxxxxxx>, the arch/x86 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>, zach.brown@xxxxxxxxxx, Ingo Molnar <mingo@xxxxxxxxxx>, chris.mason@xxxxxxxxxx |
|
Delivery-date: |
Mon, 02 Nov 2009 07:42:26 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<861f0a3e-8d6f-473e-a67d-80e46343fedd@default> |
|
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> |
|
References: |
<861f0a3e-8d6f-473e-a67d-80e46343fedd@default> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 |
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
|
|
|
| |
|
Home