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 3123DE80A91 for ; Wed, 27 Sep 2023 06:01:32 +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=Drul3cEY9Cz2i/xkCc7NUBNlGxsXHzb1lAnv/sAnkqw=; b=FKFiCOrlZQAj4B u1SgJNqFdnQMwvpY4T/JLOA3syJ9pCrqG2H+1HctIwP2eKxUj/BHUzZwl4+lZdxeR5aqrObKVTvqT Pc7ddHDw8AoWBrE91pJB31uKDiKwKCisq6k/sM0Mub2YlxmQiOVadDytZEtfwV9h9TEmmuQd22q8S 9BAqfYUBPtrh/oLryswyLy1wRjny/lHFdyrr+A7cl4I6QAJ9/Gjzyc+3mn/iAjlUfiMjn4nEvf5c5 umb246CE/TgqW5JYiyJxKXu7DkBfqfy8M3ppHWmiiJ92pTIP8tHeZwQuKiNufuM16179RhiIOmbyl qexUUIN28zSr5O/PiFtg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qlNbd-00039w-1F; Wed, 27 Sep 2023 06:01:05 +0000 Received: from out-192.mta0.migadu.com ([91.218.175.192]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qlNb8-0002uD-05 for linux-arm-kernel@lists.infradead.org; Wed, 27 Sep 2023 06:00:36 +0000 Date: Wed, 27 Sep 2023 06:00:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1695794425; 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=3hbQpc4UesV7IX0JvCrTUx6QA3LAg9gDtHymuaQldZw=; b=eifoM+TFNp9/h7Xw9Ksm3RmCyTja/wb9Dr3OWTc22KJpHs9wmNbtVeET3FYkloyTu7fIjd E4bRUlHqgYeMPyaiXAUsLVgNAXBqbN2+i4L2JojMXPPPRKd61taTGJJYHyYST+kc+3gprs QgKoQIfrsbwo964baGJO29+Ss2z6v/0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Kristina Martsenko Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Marc Zyngier , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Vladimir Murzin , Colton Lewis , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/2] KVM: arm64: Support for Arm v8.8 memcpy instructions in KVM guests Message-ID: References: <20230922112508.1774352-1-kristina.martsenko@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230922112508.1774352-1-kristina.martsenko@arm.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230926_230034_508657_AEB8D933 X-CRM114-Status: GOOD ( 13.89 ) 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 Kristina, On Fri, Sep 22, 2023 at 12:25:06PM +0100, Kristina Martsenko wrote: > Hi, > > This is v2 of the series to allow using the new Arm memory copy instructions > in KVM guests. See v1 for more information [1]. Thanks for sending out the series. I've been thinking about what the architecture says for MOPS, and I wonder if what's currently in the Arm ARM is clear enough for EL1 software to be written robustly. While HCRX_EL2.MCE2 allows the hypervisor to intervene on MOPS exceptions from EL1, there's no such control for EL0. So when vCPU migration occurs EL1 could get an unexpected MOPS exception, even for a process that was pinned to a single (virtual) CPU implementation. Additionally, the wording of I_NXHPS seems to suggest that EL2 handling of MOPS exceptions is only expected in certain circumstances where EL1 is incapable of handling an exception. Is the unwritten expectation then that EL1 software should tolerate 'unexpected' MOPS exceptions from EL1 and EL0, even if EL1 did not migrate the PE context? Perhaps I'm being pedantic, but I'd really like for there to be some documentation that suggests MOPS exceptions can happen due to context migration done by a higher EL as that is the only option in the context of virtualization. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel