From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 85234C433EF for ; Mon, 4 Apr 2022 05:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=u7qDpAbLvq4+RnssWqoBo8JGX+tORMDYePh6fV1w3l8=; b=m06KLLnbniF2B5 ZjmY8Idf3IJv4J+H03sVha7ueA4cuIE4tw+4GMn4nENtwclI1z4uBY1DxlpQTzT8gzxkAr5Ve7fo9 1sloExTEtBO7ACkVpsrsI8MsaghuZERjtbnllcoERfZO34baiYlWWBsLp2DN2nh1H2VwfF+BNrdkB mFMwQGTGX1aWOxzXerpCBubf+5f0dk1OzO/UgeyX22oUUaZ8fBZ0ZchfKWGaXGUY+rOoAyZx7nWDy HW+CNeaaSxLTOz77J7Uabu6lYDw8r2QMNaPV2/d5+CFV3q7uMWTYFYhq5Q5Ilo1nnQm7O5ryBkXPo XdGlBbjLD+6uobRp5l2g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbFY9-00DLm0-2H; Mon, 04 Apr 2022 05:46:49 +0000 Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbFY5-00DLlD-Me for linux-arm-kernel@lists.infradead.org; Mon, 04 Apr 2022 05:46:47 +0000 Received: by mail-il1-x12c.google.com with SMTP id y16so6117584ilc.7 for ; Sun, 03 Apr 2022 22:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2PyI5wE/9y9aF+w53ak3NL4bdwUIasxuc/+R7nGVlkM=; b=PxHyTiTYyZKrMuWxWAtFUKNTUBv0DkB5ESh3olcmowfb91vjP4mIB7ltmXbb2EO4Ie Hn0GeRK0D5M7MuTpjuO0c0ZlZ8iZQ/XmZtXmlP99/R0r96jXGsRC9Rg2Z7tyOjohujoK Exx+VXoicxCd8wiN4wdqkV57XoUl5gQK7+e9WVsQlGV/2nNKh7iP2ODGiWqdf17NlQWw O6YzGl8E4RjpQY1S3mcUEN4b2S/wkpOiqXJVrRFQGo55cLTpbOF4Kvj+c74BP58sbdSr CVSYMWo6Z1criwdhMT2FOZSupAaTY8VHQ4PyFm6dsg4GnoiusW8Ooh80FsqNa2CLMHh9 04qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2PyI5wE/9y9aF+w53ak3NL4bdwUIasxuc/+R7nGVlkM=; b=Ex3nzBVpOPGN8JMVQPxdC+7Fva/yASnXQpoQIIdV6NTMZ1vF1S7RQltVl4vzXvZyMO ePFwwNfkIpLXXtokXFKF8+/Cag2mM2aR/GLy7+F4wSJj75q2/N1pg8LGM5+vpDT4GLEP ASMEjS1h+TKK0DpdDCjKYDwS5JyMAUEuU2nGvU+O7h0iMHpy1WbxusFZi/ohIeX2uaW7 EpcbxlzX1XaUjsLxFzg3dtOD56q4+iuW8j7OrN6tC51onjVsaUF9ga4C2VpRaX+3TBvh AK9GaiO0KirrVibVF45rVrWvq4aS5Fd0UmWBzZJUM92klaPO3Vu2qkvbPqX51ZjvL2KY 6ehw== X-Gm-Message-State: AOAM531YryWggJlVnxJ4udr56z0p1IoZ4dUVz64erm7RkYNZ79184QJa Vhq9rz0zCBDjrAC1TF16AYHn043+nQfVfw== X-Google-Smtp-Source: ABdhPJwk+57GkB2Zn+ajUSVOFh+5njhU0KQCOdF0/4uXoez1/cNjCep9/bJs6lDeVvXeVItIol/I2g== X-Received: by 2002:a05:6e02:20c4:b0:2c9:a514:6a99 with SMTP id 4-20020a056e0220c400b002c9a5146a99mr5023931ilq.50.1649051203223; Sun, 03 Apr 2022 22:46:43 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id h24-20020a6bfb18000000b006497692016bsm5828288iog.15.2022.04.03.22.46.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Apr 2022 22:46:42 -0700 (PDT) Date: Mon, 4 Apr 2022 05:46:39 +0000 From: Oliver Upton To: Reiji Watanabe Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Linux ARM , Peter Shier , Ricardo Koller Subject: Re: [PATCH v2 3/3] KVM: arm64: Start trapping ID registers for 32 bit guests Message-ID: References: <20220401010832.3425787-1-oupton@google.com> <20220401010832.3425787-4-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220403_224645_790636_9DD3E333 X-CRM114-Status: GOOD ( 20.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Reiji, On Sun, Apr 03, 2022 at 09:45:15PM -0700, Reiji Watanabe wrote: > On Thu, Mar 31, 2022 at 6:08 PM Oliver Upton wrote: > > > > To date KVM has not trapped ID register accesses from AArch32, meaning > > that guests get an unconstrained view of what hardware supports. This > > can be a serious problem because we try to base the guest's feature > > registers on values that are safe system-wide. Furthermore, KVM does not > > implement the latest ISA in the PMU and Debug architecture, so we > > constrain these fields to supported values. > > > > Since KVM now correctly handles CP15 and CP10 register traps, we no > > longer need to clear HCR_EL2.TID3 for 32 bit guests and will instead > > emulate reads with their safe values. > > > > Signed-off-by: Oliver Upton > > Reviewed-by: Reiji Watanabe > > BTW, due to this, on a system that supports PMUv3, ID_DFR0_E1 value will > become 0 for the aarch32 guest without PMUv3. This is the correct behavior, > but it affects migration. I'm not sure how much we should care about > migration of the aarch32 guest though (and it will be resolved once ID > registers become configurable anyway). I believe userspace has been accessing the sanitised values of these feature registers the entire time, so we should be OK on the UAPI side. >From the guest's perspective, I don't believe there is a meaningful change. Even if the guest were to believe the value it sees in ID_DFR0.PerfMon, it'll crash and burn on the first attempt to poke a PMU register as we synthesize an UNDEF, right? At least now we cover our tracks and ensure the vCPU correctly identifies itself to the guest. This is, of course, unless I missed something painfully obvious :) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel