All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Avi Kivity <avi@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] Allow preemption during lazy mmu updates
Date: Sun, 19 Apr 2009 16:53:19 -0700	[thread overview]
Message-ID: <49EBB96F.60300@goop.org> (raw)
In-Reply-To: <49EAF9D6.1010600@redhat.com>

Avi Kivity wrote:
> What are the slight differences in requirements?
>
> KVM wants to run in non-preemptible, interrupts-enabled context.

There are two hooks: arch_start_context_switch() in 
kernel/sched:context_switch(), and arch_end_context_switch() in 
arch/x86/kernel/process_(32|64).c.  They bound the heart of the context 
switch in which various bits of core state is changes, like the cr3 
reload, fpu TS flag, iopl, tls slots, etc.  All things which require a 
hypercall in a paravirtualized environment, and so can be batched 
together into a multicall (or whatever) to minimize the number of 
context-switch time hypercalls.  The placement of end_context_switch is 
particularly sensitive because it needs to be in the right place 
relative to fpu context reload and segment register reloading.

Preemption is definitely disabled, and interrupts as well, I think.  So 
perhaps these won't work for you.

However, looking at the fire_sched_out_preempt_notifiers() is almost in 
the same position as arch_start_context_switch(), so I think they could 
be unified one way or the other.  The sched_in notifier happens way too 
late though.  Does KVM just use both in and out, or just one?

    J

  parent reply	other threads:[~2009-04-19 23:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27 18:02 [PATCH] Allow preemption during lazy mmu updates Jeremy Fitzhardinge
2009-03-27 18:02 ` [PATCH 1/8] mm: disable preemption in apply_to_pte_range Jeremy Fitzhardinge
2009-03-27 18:02 ` [PATCH 2/8] x86/paravirt: remove lazy mode in interrupts Jeremy Fitzhardinge
2009-03-27 18:02 ` [PATCH 3/8] x86/pvops: replace arch_enter_lazy_cpu_mode with arch_start_context_switch Jeremy Fitzhardinge
2009-03-27 18:02 ` [PATCH 4/8] x86/paravirt: flush pending mmu updates on context switch Jeremy Fitzhardinge
2009-03-27 18:02 ` [PATCH 5/8] x86/paravirt: finish change from lazy cpu to context switch start/end Jeremy Fitzhardinge
2009-03-27 18:02 ` [PATCH 6/8] x86/paravirt: allow preemption with lazy mmu mode Jeremy Fitzhardinge
2009-03-27 18:02 ` [PATCH 7/8] mm: allow preemption in apply_to_pte_range Jeremy Fitzhardinge
2009-04-07 21:38   ` Andrew Morton
2009-04-07 21:54     ` Jeremy Fitzhardinge
2009-03-27 18:02 ` [PATCH 8/8] x86/paravirt: use percpu_ rather than __get_cpu_var Jeremy Fitzhardinge
2009-03-27 23:48 ` [PATCH] Allow preemption during lazy mmu updates Peter Zijlstra
2009-04-08 14:54 ` Ingo Molnar
2009-04-08 15:11   ` Peter Zijlstra
2009-04-19 10:15     ` Avi Kivity
2009-04-19 10:47       ` Peter Zijlstra
2009-04-19 23:53       ` Jeremy Fitzhardinge [this message]
2009-04-20  6:02         ` Avi Kivity
2009-04-08 17:32   ` Jeremy Fitzhardinge
2009-04-08 18:10     ` David Howells
2009-04-08 18:30       ` [PATCH] FRV: Use <asm-generic/pgtable.h> in NOMMU mode David Howells
2009-04-08 18:35         ` Jeremy Fitzhardinge
2009-04-08 18:47           ` David Howells
2009-04-08 18:44         ` Sam Ravnborg
2009-04-08 18:47           ` David Howells
2009-04-08 20:56             ` Sam Ravnborg
2009-04-08 21:25               ` David Howells
2009-04-08 21:40                 ` Sam Ravnborg
2009-04-08 21:48                   ` David Howells
2009-04-08 22:04                     ` Sam Ravnborg

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=49EBB96F.60300@goop.org \
    --to=jeremy@goop.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=avi@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.