From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH v2 0/7] arm64: KVM: vgic-v2: Allow unsafe GICV accesses Date: Tue, 6 Sep 2016 13:14:50 +0200 Message-ID: <20160906111450.GN30513@cbox> References: <1473150527-4729-1-git-send-email-marc.zyngier@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Maydell , linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu To: Marc Zyngier Return-path: Received: from mail-wm0-f51.google.com ([74.125.82.51]:34094 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754915AbcIFLMW (ORCPT ); Tue, 6 Sep 2016 07:12:22 -0400 Received: by mail-wm0-f51.google.com with SMTP id w207so32932954wmw.1 for ; Tue, 06 Sep 2016 04:12:22 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1473150527-4729-1-git-send-email-marc.zyngier@arm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Sep 06, 2016 at 09:28:40AM +0100, Marc Zyngier wrote: > In a number of cases, KVM cannot give access direct access to the > GICv2 GICV region, either because GICV is not page aligned, or its > size is not a multiple of the page size. This is especially visible > with 16kB/64kB pages and the original GIC-400 layout where each region > is only 4k aligned. > > Instead of disabling KVM altogether (which is the current behaviour), > there is some value in trapping each guest GICV access, performing the > access as quickly as possible at EL2, and resuming the guest. This > allows us to keep KVM enabled on this HW. > > Implementation wise, this is done with a static key controlling the > workaround being enabled, hence coming at zero cost (well, an extra > nop on the exit hot path) for unaffected platforms. On the affected > HW, I've measured a 10 to 15% overhead for a self-IPI test, which is > pretty bad, but still much better than not having a GIC at all. > > There is two pending issues: > > - A failed write to GICV ends up being forwarded to userspace. This > will be addressed in a follow-up series where we deal with injecting > vSError in the guest > > - Skipping instructions (as we do when emulating anything) breaks > things like guest single-step and watchpoints. This is a long > standing problem, and someone should probably have a look at > it. Alex? > > Tested on Juno-r1 with 64kB pages. I also tested this on TC2 to ensure we didn't regress the 32-bit side. Applied the series. -Christoffer