public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Avi Kivity <avi@redhat.com>
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	kurt.hackel@oracle.com, Glauber Costa <glommer@redhat.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Glauber de Oliveira Costa <gcosta@redhat.com>,
	Xen-devel <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>,
	zach.brown@oracle.com, Ingo Molnar <mingo@redhat.com>,
	chris.mason@oracle.com
Subject: RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
Date: Mon, 2 Nov 2009 07:28:21 -0800 (PST)	[thread overview]
Message-ID: <861f0a3e-8d6f-473e-a67d-80e46343fedd@default> (raw)
In-Reply-To: <4AED54D1.6070706@redhat.com>

> From: Avi Kivity [mailto:avi@redhat.com]
> 
> 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

  reply	other threads:[~2009-11-02 15:29 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-06  0:50 [PATCH RFC] Extending pvclock down to usermode for vsyscall Jeremy Fitzhardinge
2009-10-06  0:50 ` [PATCH 1/5] x86/pvclock: make sure rdtsc doesn't speculate out of region Jeremy Fitzhardinge
2009-10-06  0:50 ` [PATCH 2/5] x86/pvclock: no need to use strong read barriers in pvclock_get_time_values Jeremy Fitzhardinge
2009-10-06  0:50 ` [PATCH 3/5] x86/pvclock: add vsyscall implementation Jeremy Fitzhardinge
2009-10-06  9:04   ` Avi Kivity
2009-10-06 14:19     ` Dan Magenheimer
2009-10-06 15:11       ` Avi Kivity
2009-10-06 18:46     ` [Xen-devel] " Jeremy Fitzhardinge
2009-10-07 10:25       ` Avi Kivity
2009-10-07 19:29         ` Jeremy Fitzhardinge
2009-10-07 20:09           ` Avi Kivity
2009-10-07 21:19             ` Jeremy Fitzhardinge
2009-10-07 21:37               ` Avi Kivity
2009-10-07 21:51                 ` Jeremy Fitzhardinge
2009-10-07 21:53                   ` Avi Kivity
2009-10-07 20:48         ` Dan Magenheimer
2009-10-07 21:08           ` Avi Kivity
2009-10-07 22:36             ` Dan Magenheimer
2009-10-10  0:24         ` Jeremy Fitzhardinge
2009-10-10 18:10           ` Avi Kivity
2009-10-12 18:20             ` Jeremy Fitzhardinge
2009-10-12 18:29               ` Avi Kivity
2009-10-12 19:13                 ` Jeremy Fitzhardinge
2009-10-13  6:39                   ` Avi Kivity
2009-10-13 20:00                     ` Jeremy Fitzhardinge
2009-10-14 12:32                       ` Avi Kivity
2009-10-15 19:17                         ` Jeremy Fitzhardinge
2009-10-27 17:29                         ` Dan Magenheimer
2009-10-27 18:20                           ` Jeremy Fitzhardinge
2009-10-28  5:52                             ` Avi Kivity
2009-10-28  9:29                               ` Glauber Costa
2009-10-28  9:34                                 ` Avi Kivity
2009-10-28 17:47                                   ` Jeremy Fitzhardinge
2009-10-29 12:13                                     ` Avi Kivity
2009-10-29 13:03                                       ` Chris Mason
2009-10-29 14:46                                       ` Dan Magenheimer
2009-10-29 15:07                                         ` Avi Kivity
2009-10-29 15:55                                           ` Dan Magenheimer
2009-10-29 16:15                                             ` Dan Magenheimer
2009-11-01  9:28                                               ` Avi Kivity
2009-11-02 15:28                                                 ` Dan Magenheimer [this message]
2009-11-02 15:41                                                   ` Avi Kivity
2009-11-01  9:32                                             ` Avi Kivity
2009-11-02 15:46                                               ` Dan Magenheimer
2009-11-03  5:12                                                 ` Avi Kivity
2009-11-04 20:30                                                   ` Dan Magenheimer
2009-11-05  6:47                                                     ` Avi Kivity
2009-11-05 14:52                                                       ` Dan Magenheimer
2009-11-05 15:07                                                         ` Keir Fraser
2009-11-04 21:19                                           ` john stultz
2009-11-04 21:28                                             ` Dan Magenheimer
2009-11-05  0:02                                               ` john stultz
2009-11-05  0:45                                                 ` Dan Magenheimer
2009-10-06  0:50 ` [PATCH 4/5] x86/fixmap: add a predicate for usermode fixmaps Jeremy Fitzhardinge
2009-10-06 10:23   ` [Xen-devel] " Jan Beulich
2009-10-06 18:47     ` Jeremy Fitzhardinge
2009-10-06  0:50 ` [PATCH 5/5] xen/time: add pvclock_clocksource_vread support Jeremy Fitzhardinge
2009-10-06 10:28   ` [Xen-devel] " Jan Beulich
2009-10-06 18:48     ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=861f0a3e-8d6f-473e-a67d-80e46343fedd@default \
    --to=dan.magenheimer@oracle.com \
    --cc=avi@redhat.com \
    --cc=chris.mason@oracle.com \
    --cc=gcosta@redhat.com \
    --cc=glommer@redhat.com \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=keir.fraser@eu.citrix.com \
    --cc=kurt.hackel@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    --cc=zach.brown@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox