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 1DB48EB64DD for ; Mon, 14 Aug 2023 09:37:59 +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:Reply-To: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:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=msqlBZfTA/gj2vzuXlEPvkCeOyjnyYs00v3KjgYxO34=; b=JTDJjcK4lz6FRA KFCeEuqF//lb9vdLkv9a8BZfCdwB4iepXsYCaJoZa16365UF5SP/7Jk167JsUEHRDTKwKD1ObW14Q 7vg2H7Vzfl72RbxJb0BKOXPoLhjz/FIWVNvIMTIJA8QTnInZ/aZLg5BVa3UIQ8uoyzXeUyxPP2r3C qiID3x2Yl7+9TkLvPZT1e0NWdESvVbLlHNktO2YzqT9TGxbUFS2qSGb90qJVfCe6g9lbEn7dfVVcb oqZjQefLSyJITmVe9s5v8Vs6GkqQLK+oRmWELZpeZDpDUM7X4QH+u+IXUBEaO15bCrtcpQo2ADfEG C2wJWkLs5mCbiNw2/VZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qVU10-00GdB9-0h; Mon, 14 Aug 2023 09:37:34 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qVU0x-00Gd7L-0P for linux-arm-kernel@lists.infradead.org; Mon, 14 Aug 2023 09:37:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692005832; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G2CQ2r2nKutez4n7L0Q2/gUAsc9OoG5P9/PB8IXCPoc=; b=Hpujj8lcNEYXt+kFjltBxIeNRJx574wc60zR9ja6wgQLMceoY9/EUTmRfs1Cq5W4GHuxkR 8L7bd08g/TFL0YCyZMoiUHIYkUfdnNGZUKNtpGV09hRt0DXaZJHyX8h/MqfuUVLKkbyX7T tjX43Kjh9/LOr5JHO7AZ/BwPyosJI0I= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-54-oIBLs86CO0-YBuykXvIj2g-1; Mon, 14 Aug 2023 05:37:11 -0400 X-MC-Unique: oIBLs86CO0-YBuykXvIj2g-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-40ffb00bfc4so40502541cf.3 for ; Mon, 14 Aug 2023 02:37:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692005830; x=1692610630; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:reply-to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=G2CQ2r2nKutez4n7L0Q2/gUAsc9OoG5P9/PB8IXCPoc=; b=H6t8MCWExd5Y+x7kMe/LqaU3BDLph8YHJ8HgrD4BvVOWlO8BU5P/XlbedVkK8WJIPn HRo5p2W1UT2o2SBfGqq4T8/6xd6TlyJP19Z2EPqZq3D1WuYq28dz4L6jAqN+ZEWzXrfK zIIGPOIkeB7jEtIAgAnK/U+duw4+f6IalB+UoYV+A3gy/+diDxduCtR6Ej7t2CStFEys Zb/FBzjayXy3XH+vPaMHzvbTqLHj0yUgVSuHG/mk+154N0VgRtv5OIhopSKhZ/iCeUab 1pEGZfdguxbOV3IborybtT8q90oSDwqb1hC2XtTzmzZvH4NvbFMnkSTJ6Yl7KnZXrhu4 Z09Q== X-Gm-Message-State: AOJu0YyzY0hVmnKIQI9I4GyJr3rwg28bp9jVGdzJ1imf0L2sOIyPvfcv //rdKn5cIeMrKXWyjEAOtq4Z17DisOLPbQTzQhVxinqNKM+Pdh1Mc5+2XxnBqUIyiQtXKlekogi 3A63XKVWDosFUcpNtjDlNuQNUq6yZGV2QENA= X-Received: by 2002:ac8:5810:0:b0:410:31c4:f460 with SMTP id g16-20020ac85810000000b0041031c4f460mr12629773qtg.1.1692005830641; Mon, 14 Aug 2023 02:37:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHJr+VgF7cwi7o4O7By8vYXhInX3L9u/p0leCSsoLsabz50pa39tlAYfaMySbJvuaIj6fvQBQ== X-Received: by 2002:ac8:5810:0:b0:410:31c4:f460 with SMTP id g16-20020ac85810000000b0041031c4f460mr12629747qtg.1.1692005830379; Mon, 14 Aug 2023 02:37:10 -0700 (PDT) Received: from ?IPV6:2a01:e0a:59e:9d80:527b:9dff:feef:3874? ([2a01:e0a:59e:9d80:527b:9dff:feef:3874]) by smtp.gmail.com with ESMTPSA id t4-20020ac86a04000000b00405447ee5e8sm2971171qtr.55.2023.08.14.02.37.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Aug 2023 02:37:09 -0700 (PDT) Message-ID: <3f22f28e-f106-392f-102e-cba8ee3c0ab5@redhat.com> Date: Mon, 14 Aug 2023 11:37:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v3 23/27] KVM: arm64: nv: Add SVC trap forwarding To: Marc Zyngier Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Catalin Marinas , Mark Brown , Mark Rutland , Will Deacon , Alexandru Elisei , Andre Przywara , Chase Conklin , Ganapatrao Kulkarni , Darren Hart , Miguel Luis , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu References: <20230808114711.2013842-1-maz@kernel.org> <20230808114711.2013842-24-maz@kernel.org> <2a751a64-559e-cb17-4359-7f368c1b42ca@redhat.com> <87wmy3p4ac.wl-maz@kernel.org> <527eddd0-b069-3b58-d82e-97b758c128ab@redhat.com> <861qgaghen.wl-maz@kernel.org> From: Eric Auger In-Reply-To: <861qgaghen.wl-maz@kernel.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230814_023731_267540_A246E8D5 X-CRM114-Status: GOOD ( 29.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: , Reply-To: eric.auger@redhat.com 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 Marc, On 8/11/23 09:36, Marc Zyngier wrote: > On Thu, 10 Aug 2023 18:30:25 +0100, > Eric Auger wrote: >> Hi Marc, >> On 8/10/23 12:42, Marc Zyngier wrote: >>> Hi Eric, >>> >>> On Thu, 10 Aug 2023 09:35:41 +0100, >>> Eric Auger wrote: >>>> Hi Marc, >>>> >>>> On 8/8/23 13:47, Marc Zyngier wrote: >>>>> HFGITR_EL2 allows the trap of SVC instructions to EL2. Allow these >>>>> traps to be forwarded. Take this opportunity to deny any 32bit activity >>>>> when NV is enabled. >>>> I can't figure out how HFGITR_EL2.{SVC_EL1, SVC_EL0 and ERET} are >>>> handled. Please could you explain. >>> - SVC: KVM itself never traps it, so any trap of SVC must be the >>> result of a guest trap -- we don't need to do any demultiplexing. We >>> thus directly inject the trap back. This is what the comment in >>> handle_svc() tries to capture, but obviously fails to convey the >>> point. >> Thank you for the explanation. Now I get it and this helps. >>> - ERET: This is already handled since 6898a55ce38c ("KVM: arm64: nv: >>> Handle trapped ERET from virtual EL2"). Similarly to SVC, KVM never >>> traps it unless we run NV. >> OK >>> Now, looking into it, I think I'm missing the additional case where >>> the L2 guest runs at vEL1. I'm about to add the following patchlet: >>> >>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c >>> index 3b86d534b995..617ae6dea5d5 100644 >>> --- a/arch/arm64/kvm/handle_exit.c >>> +++ b/arch/arm64/kvm/handle_exit.c >>> @@ -222,7 +222,22 @@ static int kvm_handle_eret(struct kvm_vcpu *vcpu) >>> if (kvm_vcpu_get_esr(vcpu) & ESR_ELx_ERET_ISS_ERET) >>> return kvm_handle_ptrauth(vcpu); >>> >>> - kvm_emulate_nested_eret(vcpu); >>> + /* >>> + * If we got here, two possibilities: >>> + * >>> + * - the guest is in EL2, and we need to fully emulate ERET >>> + * >>> + * - the guest is in EL1, and we need to reinject the >>> + * exception into the L1 hypervisor. >> but in the case the guest was running in vEL1 are we supposed to trap >> and end up here? in kvm_emulate_nested_eret I can see >> "the current EL is always the vEL2 since we set the HCR_EL2.NV bit only >> when entering the vEL2". > If the guest is running at vEL1, the only ways to trap ERET are: > > - if the guest hypervisor has set HFGITR_EL2.ERET, because the host > KVM never sets that bit on its own > > - or if the guest hypervisor has set HCR_EL2.NV (which we don't really > handle so far, as we don't expose FEAT_NV to guests). > > If the guest is running at vEL2, then it is HCR_EL2.NV that is > responsible for the trap, and we perform the ERET emulation. makes sense to me. Explanation about HFGITR_EL2.ERET case is helpful and may be worth to be added as a comment. > >> But I am still catching up on the already landed >> >> [PATCH 00/18] KVM: arm64: Prefix patches for NV support >> >> so please forgive me my confusion ;-) > Confusion is the whole purpose of NV, so don't worry, you're in good > company here! :D :-) Eric > > Thanks, > > M. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel