From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Date: Sat, 03 Oct 2009 10:08:20 +0000 Subject: Re: [PATCH 00/27] Add KVM support for Book3s_64 (PPC64) hosts v4 Message-Id: <4AC72294.3020500@redhat.com> List-Id: References: <1254212303-8737-1-git-send-email-agraf@suse.de> In-Reply-To: <1254212303-8737-1-git-send-email-agraf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org On 10/02/2009 02:32 AM, Benjamin Herrenschmidt wrote: > On Wed, 2009-09-30 at 11:24 +0200, Avi Kivity wrote: > > >> But writing those registers often has side effects. For example, >> enabling interrupts should also inject an interrupt when one is >> pending. On x86 we have the same problem with the TPR on Windows XP, so >> we copy it to the guest on entry (along with the pending interrupt >> state) and back to the host on exit. The guest uses an atomic operation >> to change the TPR and read pending interrupt information, and if an >> interrupt becomes unmasked, it calls a hypercall to trigger it. >> >> Presumably you'll be doing something similar? >> >> In any case, I recommend keeping fine-grained control over those bits so >> they can be enabled/disabled/expanded as needed. >> > Sure, for those who have side-effects, special care must be taken, > either with PV tricks as Alex suggested in another reply, or by > emulation. > > But for example, pretty much every time the MSR is written, it's also > previously -read-. If we keep a shadow of the guest MSR in the "magic > page", then we can already half the number of emulation traps simply > by having the guest read from there instead, and still trap on writes. > > Those reads don't have side effects. > So these MSRs can be modified by the hypervisor? Otherwise you'd cache them in the guest with no hypervisor involvement, right? (just making sure :) > There's also a bunch of SPRs that don't have a direct side effect such > as the SRRs and SPRGs which are heavily used for exception entry and > exit. The former are storage for the PC and MSR values for a subsequent > rfi instruction (return from interrupt) and the later are just general > purpose storage for the kernel to save a few GPRs into in the exception > handling code. > > By replacing these by, for example, absolute load/stores in a magic > page mapped differently per-CPU (one trick we have in mind) we can > very significantly speed up the guest kernel exception entry and exit, > and this is without dealing with side effects. > > As Alex mention, we can from there try to go further for things like > MSR changes, but you are right that this needs to be done more > carefully. > Thanks for the explanations. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.