From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: "Nakajima, Jun" <jun.nakajima-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: Status of SMP?
Date: Fri, 16 Mar 2007 08:46:07 +0200 [thread overview]
Message-ID: <45FA3D2F.4070603@qumranet.com> (raw)
In-Reply-To: <8FFF7E42E93CC646B632AB40643802A8023B861B-1a9uaKK1+wJcIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Nakajima, Jun wrote:
> I assumed that the current virutal MMU code was not designed to support
> SMP (when you said "there's no need to worry about the mmu").
What I meant was that there is no need debug both the core smp support
and the mmu smp support at the same time. Certainly the mmu was written
with smp support in mind.
> The other thing is how do you detect when the guest page tables become
> just data (this is not an SMP issue, though)? If you don't unshadow such
> pages, we'll tend to get (frequent) unnecessary #PF.
>
There are a few heuristics in place for zapping shadow page tables:
- user mode writes (fix_write_pf)
- unaligned writes (kvm_mmu_pre_write)
- lots of writes to the same page (kvm_mmu_pre_write)
We could probably also add a heuristic that checks that the contents
look like a pte if PT_PRESENT is set. This is useful mostly on pae
where there are many reserved bits.
> These are mostly performance optimization issues, but SMP guests will
> use local and IO APICs (and other misc timers), and we'll see more
> frequent VM exits in such a guest. We may need to move them to the KVM
> side if we see performance issues.
>
We've actually done this, and found that performance was not affected.
The reason is that the kernel->user transition is very fast compared to
the guest->kernel transition. It is still worthwhile to do this if we
have to use the apic to inject interrupts from in-kernel paravirtualized
devices, where it makes little sense to go back to userspace in order to
inject the interrupt.
I'd also like to add a read-only memory type so that apic reads can
proceed natively rather than be emulated (the TODO has this now).
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
next prev parent reply other threads:[~2007-03-16 6:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-13 12:47 Status of SMP? Gregory Haskins
[not found] ` <45F66525.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org>
2007-03-13 13:16 ` Avi Kivity
[not found] ` <45F67F12.BA47.005A.0@novell.com>
[not found] ` <45F6B962.9070301@qumranet.com>
[not found] ` <45F684E7.BA47.005A.0@novell.com>
[not found] ` <45F6BEC0.1010906@qumranet.com>
[not found] ` <45F68E68.BA47.005A.0@novell.com>
2007-03-13 15:47 ` Fwd: " Gregory Haskins
[not found] ` <45F6A426.9090004-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-03-14 21:09 ` Nakajima, Jun
[not found] ` <8FFF7E42E93CC646B632AB40643802A802385E65-1a9uaKK1+wJcIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-03-15 8:43 ` Avi Kivity
[not found] ` <45F90728.2040207-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-03-15 22:08 ` Nakajima, Jun
[not found] ` <8FFF7E42E93CC646B632AB40643802A8023B861B-1a9uaKK1+wJcIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-03-16 6:46 ` Avi Kivity [this message]
[not found] ` <45FA3D2F.4070603-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-03-16 15:21 ` Nakajima, Jun
[not found] ` <8FFF7E42E93CC646B632AB40643802A8023B8983-1a9uaKK1+wJcIJlls4ac1rfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2007-03-18 5:48 ` Avi Kivity
2007-03-16 14:35 ` Huang2, Wei
2007-03-16 17:51 ` Huang2, Wei
[not found] ` <7D748C767B7FA541A8AC5504A4C89A23015685C1-SXV0rU3j2e+jL8BtgrxzBQC/G2K4zDHf@public.gmane.org>
2007-03-18 5:14 ` Avi Kivity
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=45FA3D2F.4070603@qumranet.com \
--to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
--cc=jun.nakajima-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox