From patchwork Tue Oct 3 03:09:58 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jintack Lim X-Patchwork-Id: 9981435 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1D9FB60384 for ; Tue, 3 Oct 2017 03:10:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 10A74287B7 for ; Tue, 3 Oct 2017 03:10:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 03EDF2881D; Tue, 3 Oct 2017 03:10:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_SPAM autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AB2CB287B7 for ; Tue, 3 Oct 2017 03:10:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751755AbdJCDKF (ORCPT ); Mon, 2 Oct 2017 23:10:05 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:50115 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751354AbdJCDKD (ORCPT ); Mon, 2 Oct 2017 23:10:03 -0400 Received: by mail-io0-f174.google.com with SMTP id 21so6445919iof.6 for ; Mon, 02 Oct 2017 20:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=lIjwD++ehRsww7wU/7nBiBoMYRJwM07gdmJSIt5M5yY=; b=fwCMbrjZuQ24cASZDGy5H+zy77E3i4K0MLUosOuPDabIxdd7EVPVp5NLdg+mNNQOo0 N7nXPjQCw8zFvihrKufhQSdVbrpIL79EdOU5jeXtJITuf5JyUnZV8QcqwzpGVy+Hwbnv i4TuLp4GtV5HNV0bluVS623secSp9t5ElTtTY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=lIjwD++ehRsww7wU/7nBiBoMYRJwM07gdmJSIt5M5yY=; b=cUfmrUukK+x9c4jsBkBbVyl6tqmwBF11kD8X2F4LiBP7alJiJFRdoN9iLgsKrEz7Vm kw7oQWCsG+4YrpT54AAy8BnGcnGMjEgsoDnsgkboovDc1l6qnvuevyKUmKQkzFE0WR5Y 03tcOqWxHfDna2sjbU0Uoi8JZGkPR7FNwRx9OHbzqhzUxwbvM/QhPZErroFc3tpAwwWE NGjFigUD9Ak+89CtC+vH9Gv1Kcb8TuovK6V6mxBlfVBSeZuRu+gwOohUqRCBVr+MlfHA QTUKoKANyRIeBAKDHvLh+JMA+yJmR24zGxHlKh0zxz9/709KKeclo6sxt0wZ4hr2JXBq AF9w== X-Gm-Message-State: AMCzsaV5mkb/njqJZgB+JZj4pmeWCDoIPlzbGV5mlCJoBNmChTWr/1Bv 2yMosXVRkPIU+IxSxLOXJmyn2A== X-Google-Smtp-Source: AOwi7QBvXrxKtp7JvIvFNl8udpZId7XLsLiS7mOA55P/FeOHCMDv74W4dXmUYExWT03ihAbyRq+77w== X-Received: by 10.107.183.200 with SMTP id h191mr25026452iof.144.1507000202587; Mon, 02 Oct 2017 20:10:02 -0700 (PDT) Received: from node.jintackl-qv28633.kvmarm-pg0.wisc.cloudlab.us (c220g1-031126.wisc.cloudlab.us. [128.104.222.76]) by smtp.gmail.com with ESMTPSA id 203sm5289370ioe.66.2017.10.02.20.10.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Oct 2017 20:10:02 -0700 (PDT) From: Jintack Lim To: christoffer.dall@linaro.org, marc.zyngier@arm.com, kvmarm@lists.cs.columbia.edu Cc: Dave.Martin@arm.com, jintack@cs.columbia.edu, pbonzini@redhat.com, rkrcmar@redhat.com, catalin.marinas@arm.com, will.deacon@arm.com, linux@armlinux.org.uk, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jintack Lim Subject: [RFC PATCH v2 02/31] KVM: arm64: Expose limited memory management support to the virtual EL2 Date: Mon, 2 Oct 2017 22:09:58 -0500 Message-Id: <1507000198-3635-1-git-send-email-jintack.lim@linaro.org> X-Mailer: git-send-email 1.9.1 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Exposing memory management support to the virtual EL2 as is exposed to the host hypervisor would make the implementation too complex and inefficient. Therefore expose limited memory management support for the following two cases. We expose same or larger page granules than the one host uses. We can theoretically support a guest hypervisor having smaller-than-host granularities but it is not worth it since it makes the implementation complicated and it would waste memory. We expose 40 bits of physical address range to the virtual EL2, because we only support a 40bit IPA for the guest. Signed-off-by: Jintack Lim --- arch/arm64/kvm/sys_regs.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 46 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 65f4c20..395b964 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1233,6 +1233,50 @@ static int set_raz_id_reg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, .set_user = set_raz_id_reg, \ } +static bool access_id_aa64mmfr0_el1(struct kvm_vcpu *v, + struct sys_reg_params *p, + const struct sys_reg_desc *r) +{ + u64 val; + u64 vtcr_tg0 = VTCR_EL2_TGRAN_FLAGS & VTCR_EL2_TG0_MASK; + + if (!nested_virt_in_use(v)) + return access_id_reg(v, p, r); + + if (p->is_write) + return write_to_read_only(v, p, r); + + val = p->regval; + /* + * Don't expose granules smaller than the host's granule to the guest. + * We can theoretically support a guest hypervisor having + * smaller-than-host granularities but it is not worth it since it + * makes the implementation complicated and it would waste memory. + */ + switch (vtcr_tg0) { + case VTCR_EL2_TG0_64K: + /* 16KB granule not supported */ + val &= ~(0xf << ID_AA64MMFR0_TGRAN16_SHIFT); + val |= (ID_AA64MMFR0_TGRAN16_NI << ID_AA64MMFR0_TGRAN16_SHIFT); + /* fall through */ + case VTCR_EL2_TG0_16K: + /* 4KB granule not supported */ + val &= ~(0xf << ID_AA64MMFR0_TGRAN4_SHIFT); + val |= (ID_AA64MMFR0_TGRAN4_NI << ID_AA64MMFR0_TGRAN4_SHIFT); + break; + default: + break; + } + + /* Expose only 40 bits physical address range to the guest hypervisor */ + val &= ~(0xf << ID_AA64MMFR0_PARANGE_SHIFT); + val |= (0x2 << ID_AA64MMFR0_PARANGE_SHIFT); /* 40 bits */ + + p->regval = val; + + return true; +} + /* * sys_reg_desc initialiser for known ID registers that we hide from guests. * For now, these are exposed just like unallocated ID regs: they appear @@ -1309,7 +1353,8 @@ static int set_raz_id_reg(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd, ID_SANITISED(ID_PFR1_EL1), ID_SANITISED(ID_DFR0_EL1), ID_HIDDEN(ID_AFR0_EL1), - ID_SANITISED(ID_MMFR0_EL1), + { SYS_DESC(SYS_ID_MMFR0_EL1), access_id_aa64mmfr0_el1, NULL, 0, 0, + get_id_reg, set_id_reg }, ID_SANITISED(ID_MMFR1_EL1), ID_SANITISED(ID_MMFR2_EL1), ID_SANITISED(ID_MMFR3_EL1),