All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
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: Mon, 20 Apr 2009 09:02:41 +0300	[thread overview]
Message-ID: <49EC1001.50905@redhat.com> (raw)
In-Reply-To: <49EBB96F.60300@goop.org>

Jeremy Fitzhardinge wrote:
> 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?

Both.  sched_out loads the host MSR_STAR and friends, sched_in loads the 
guest values.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


  reply	other threads:[~2009-04-20  6:05 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
2009-04-20  6:02         ` Avi Kivity [this message]
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=49EC1001.50905@redhat.com \
    --to=avi@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=jeremy@goop.org \
    --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.