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 82D1CC4345F for ; Wed, 1 May 2024 08:15:37 +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=h1xbkTfxCC2fpbMqiImG8VRm9uaVI8IinS1ByyXl3wY=; b=Qlp+iz6hPwsy2k YImaBIL7O2Dc0Zsus9jKRbD2s9xh7l7+auA6Eruqc+bRRkEnIqIrMI3P8y4Cz7q8y0TPf2yg3yGNA 9SUGj6Erz0kENFaXjbMNqdMpZJDMFAXdtYp/uEAyUytDIpNpk037mnR9gjHiaSnM7UE1Kto1jAi2D wUygpu9KOwN5Cg/ypO1a6vX1cxOoUBOIqHA4GyB99E+zf6vr1bAPXo5MEXH82a2HjvM/k/CknLYPP aEhqAbKc7HGfnhnHmR5mSMc18Ez7rDWWlW4fyRhxGN4Gday/VLS1NejQWbwpxCDhvsfNc9MgtL2G3 rQthU0uKo+N+47vEl+Iw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s257b-00000008pse-02XS; Wed, 01 May 2024 08:15:23 +0000 Received: from out-187.mta0.migadu.com ([2001:41d0:1004:224b::bb]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s257V-00000008ps8-3CpE for linux-arm-kernel@lists.infradead.org; Wed, 01 May 2024 08:15:20 +0000 Date: Wed, 1 May 2024 08:15:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1714551314; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TSsx32/ply0qM4GB61tWhNu0UvneClxiNJiY3Z5qlaI=; b=t1E3ayFIe3f4752O8dHB//FsppPZyNcvHUnynnhfdbKS7VEKvngjuZv+iBN7BQ7AlqYPIH tSYIFgV3BfRxYHkWb08Zp5qTNC4BYiMtY4MYW1AT+lGsvE2Sb6fZ2pJlKk4IiJmsfUEAdd ImeLonVITPJw+xyS/F0RBD3HZ0aMD04= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sebastian Ott Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, Marc Zyngier , James Morse , Suzuki K Poulose , Catalin Marinas , Will Deacon Subject: Re: [PATCH v2 4/6] KVM: arm64: add emulation for CTR_EL0 register Message-ID: References: <20240426104950.7382-1-sebott@redhat.com> <20240426104950.7382-5-sebott@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240426104950.7382-5-sebott@redhat.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240501_011518_525816_956D0ABC X-CRM114-Status: GOOD ( 18.02 ) 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 On Fri, Apr 26, 2024 at 12:49:48PM +0200, Sebastian Ott wrote: > CTR_EL0 is currently handled as an invariant register, thus > guests will be presented with the host value of that register. > > Add emulation for CTR_EL0 based on a per VM value. Userspace can > switch off DIC and IDC bits and reduce DminLine and IminLine sizes. > > When CTR_EL0 is changed validate that against CLIDR_EL1 and CCSIDR_EL1 > to make sure we present the guest with consistent register values. > Changes that affect the generated cache topology values are allowed if > they don't clash with previous register writes. Sorry I didn't speak up earlier, but I'm not sold on the need to cross-validate userspace values for the cache type registers. KVM should only be concerned about whether or not the selected feature set matches what hardware is capable of and what KVM can virtualize. So in the context of the CTR and the cache topology, I feel that they should be _separately_ evaluated against the host's CTR_EL0. Inconsistencies between fields in userspace values should be out of scope; userspace shares the responsibility of presenting something architectural, especially if it starts modifying ID registers. Otherwise I'm quite worried about the amount of glue required to plumb exhaustive consitency checks for registers, especially considering the lack of ordering. Marc, I know this goes against what you had suggested earlier, is there something in particular that you think warrants the consistency checks? > +static u64 reset_ctr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd) > +{ > + vcpu->kvm->arch.ctr_el0 = read_sanitised_ftr_reg(SYS_CTR_EL0); > + return vcpu->kvm->arch.ctr_el0; > +} > + We definitely do not want this value to change across a vCPU reset, it should be handled like the other ID registers where they only get reset once for the VM lifetime. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel