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 83418C4332F for ; Fri, 2 Dec 2022 09:56:36 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZxXRixKdpZ9BhW9uLRXlz92mosGh59u9pM5rcqu60YM=; b=t8arxlHdUC8tRZ 58f6dJiKFtDb6ceWuFMLmt+ZGbLFdImtLYzeEEYiZk0OxVACQIO4TygreEqbYtmCCFVmtSvtezzrl wNcWzDCrHjsFzBDoHEpovwoRgvMZ/ldIYNO9djcAOThe2nnrEUHB1a6SrqXJrwD3y7QJ/Ix4xLF0v y+VMQreRHyI3lCKfMaTgRFXOjWt5DmvZ5R8DhCjr0kvjFSe6xVUorib/c6Ru3Ud/BQKnooZWgNL8I UbKJECvHFkQ8tA4aXWf6VYpXdIQCsXBSbAgT5nCjS4Ev1+vAAf55gomFbwowV1z/BTU3PZ06Ym/m/ K1uI4Xw2qlVGYCBdrd3g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p12lf-00FBI0-4f; Fri, 02 Dec 2022 09:55:39 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p12lZ-00FBDy-V4 for linux-arm-kernel@lists.infradead.org; Fri, 02 Dec 2022 09:55:35 +0000 Received: by mail-pl1-x62f.google.com with SMTP id y4so4197896plb.2 for ; Fri, 02 Dec 2022 01:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SiNH+J33VpyIQDYVvWeq7Cr+JtDYqACf4JbEasUl180=; b=F0CI7XedxSQCcnKRIkZSxjtelGz9DSWh5cWO9aQfJorTeZDaYnJynPxfX7GoFKQ29j cwVU0Rg0wtPS7tBi+6PcyAgITcvp2twH/fqGXXgRRgDfrwYcwwlJFAJsjJbvjHzyAeU6 1T4TDvn8Lk9tP1hag0Go94jolQrB4VYh96lwa+q8QsMBJOQIvdYCwzbx5Ieuyfw1ZCxu Idzcl1YOFDobBWi3soxwWY+Vl5bQ043PDlSi+qRmotpkGrqC4uoo9FJCvou4wIgk9IQ2 8mvyiz90lU2S/Sc3yJKVRMkTBws7x5m2A5aqM8d+CuFukjigIsn3cT8uLcBFkM7ewWls DmyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SiNH+J33VpyIQDYVvWeq7Cr+JtDYqACf4JbEasUl180=; b=NUI8N1fHWFf1GL7y6gsXJcKHTv0UDD4TaLTl/tnuAVHzPqE22/sIaYz04Btda9yb00 AI4peecSzLwc1AHHF1/nmtRMOK3XhK3QbMpe0XtXf6b9doXAVCQNGKy1dCC9Tv+QVh11 qfj9UKLc+Qw226HrOGXp6lCU2mXP6Z1YAR3qMnytNPUEmYvayarhXc/AB9IG94oGASEd F/oTOA1WCP9oNJhWGSOl1cODwlem45lMfD7Oe9MHeIdroNC0fBtwK/0uCMK3iB9YL4m8 iZZFyP6rBxvGkC/i6pHZi6bOZT/sufgX2MoYoBjoK8OhT/us7iIN10fkU4urmyoOXPGX fKtQ== X-Gm-Message-State: ANoB5pkMDVvYBzpMMS4oSfzfjBN7yrm5u/e0kEjStHBKs42wd5xWO3wF 07gH7nNnLQqcK+/czBimS6Q= X-Google-Smtp-Source: AA0mqf63Cfx6DN4ieT70IkDlzzYu/aJCUI5CVTk21hXSBeKgLZNTwJo7rTYDppkPPNMBI3gzxSB1qg== X-Received: by 2002:a17:903:22c4:b0:184:cb7e:ba36 with SMTP id y4-20020a17090322c400b00184cb7eba36mr51321205plg.57.1669974930149; Fri, 02 Dec 2022 01:55:30 -0800 (PST) Received: from ?IPV6:2400:4050:c360:8200:8ae8:3c4:c0da:7419? ([2400:4050:c360:8200:8ae8:3c4:c0da:7419]) by smtp.gmail.com with ESMTPSA id 133-20020a62148b000000b0056c3a0dc65fsm4675471pfu.71.2022.12.02.01.55.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Dec 2022 01:55:29 -0800 (PST) Message-ID: Date: Fri, 2 Dec 2022 18:55:24 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH 0/3] KVM: arm64: Handle CCSIDR associativity mismatches Content-Language: en-US To: Marc Zyngier , Akihiko Odaki Cc: linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Mathieu Poirier , Oliver Upton , Suzuki K Poulose , Alexandru Elisei , James Morse , Will Deacon , Catalin Marinas , asahi@lists.linux.dev, Alyssa Rosenzweig , Sven Peter , Hector Martin References: <20221201104914.28944-1-akihiko.odaki@daynix.com> <867czbmlh1.wl-maz@kernel.org> <50499ee9-33fe-4f5d-9d0a-76ceef038333@daynix.com> <87lenqu37t.wl-maz@kernel.org> <525ff263-90b3-5b12-da31-171b09f9ad1b@daynix.com> <87h6yeta8b.wl-maz@kernel.org> From: Akihiko Odaki In-Reply-To: <87h6yeta8b.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221202_015534_077146_D2F8B426 X-CRM114-Status: GOOD ( 32.95 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022/12/02 18:40, Marc Zyngier wrote: > On Fri, 02 Dec 2022 05:17:12 +0000, > Akihiko Odaki wrote: >> >>>> On M2 MacBook Air, I have seen no other difference in standard ID >>>> registers and CCSIDRs are exceptions. Perhaps Apple designed this way >>>> so that macOS's Hypervisor can freely migrate vCPU, but I can't assure >>>> that without more analysis. This is still enough to migrate vCPU >>>> running Linux at least. >>> >>> I guess that MacOS hides more of the underlying HW than KVM does. And >>> KVM definitely doesn't hide the MIDR_EL1 registers, which *are* >>> different between the two clusters. >> >> It seems KVM stores a MIDR value of a CPU and reuse it as "invariant" >> value for ioctls while it exposes the MIDR value each physical CPU >> owns to vCPU. > > This only affects the VMM though, and not the guest which sees the > MIDR of the CPU it runs on. The problem is that at short of pinning > the vcpus, you don't know where they will run. So any value is fair > game. Yes, my concern is that VMM can be confused if it sees something different from what the guest on the vCPU sees. >> crosvm uses KVM on big.LITTLE processors by pinning >> vCPU to physical CPU, and it is a real-world application which needs >> to be supported. >> >> For an application like crosvm, you would expect the vCPU thread gets >> the MIDR value of the physical CPU which the thread is pinned to when >> it calls ioctl, but it can get one of another arbitrary CPU in >> reality. > > No. It will get the MIDR of the CPU it runs on. Check again. What you > describing above is solely for userspace. By "ioctl", I meant the value the VMM gets for the vCPU thread. The problem is that the guest on the vCPU and the VMM issuing ioctl on the same thread can see different values, and it doesn't seem quite right. >> ...or we may just say the value of MPIDR_EL0 (and possibly other > > I assume you meant MIDR_EL1 here, as MPIDR_EL1 is something else (and > it has no _EL0 equivalent). Yes, I meant MIDR_EL1. > >> "invariant" registers) exposed via ioctl are useless and deprecated. > > Useless? Not really. The all are meaningful to the guest, and a change > there will cause issues. > > CTR_EL0 must, for example, be an invariant. Otherwise, you need to > trap all the CMOs when the {I,D}minLine values that are restored from > userspace are bigger than the ones the HW has. Even worse, when the > DIC/IDC bits are set from userspace while the HW has them cleared: you > cannot mitigate that one, and you'll end up with memory corruption. > > I've been toying with the idea of exposing to guests the list of > MIDR/REVIDR the guest is allowed to run on, as a PV service. This > would allow that guest to enable all the mitigations it wants in one > go. > > Not sure I have time for this at the moment, but that'd be something > to explore. > > [...] I meant that the values exposed to the VMM via ioctls does not seem useful. They still need to be exposed to the guest as you say. Regards, Akihiko Odaki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel