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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A854C4338F for ; Thu, 29 Jul 2021 13:49:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 74AA160EB5 for ; Thu, 29 Jul 2021 13:49:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237874AbhG2NtC (ORCPT ); Thu, 29 Jul 2021 09:49:02 -0400 Received: from wforward5-smtp.messagingengine.com ([64.147.123.35]:33165 "EHLO wforward5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237831AbhG2Nsx (ORCPT ); Thu, 29 Jul 2021 09:48:53 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailforward.west.internal (Postfix) with ESMTP id A60611AC0113; Thu, 29 Jul 2021 09:48:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 29 Jul 2021 09:48:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=9QPW2T aD5TkdBoSC7awJVUB3Oz/9pHuBCU2Rqw2XRmM=; b=UX5PL0C7EKdRQuy+w/FfN1 Bgu9VREKmyd4QqYE2mhCz63k7Z7Nld6DHJpjKy1I0Z94U3NlpQts+L4MhXK/oskt jcOyiHibEl2xKYk2Kkzp1keMK0qQiWq8skd4R6r2uwp6trW+wQg2Mduso3jLFWlR Nz7HqI4TqKDkSRa3xj4k/i3BG9RO57RttgUveqArp3QmP7pRna23+aEviFJqB1Dq NDnPKGs7YygNQ41QOxZ1X8KcQngsJXtJEjIMbnxCuAbaqlXe9kYmNcao3l9aZhAZ ygJ/TyiLHPeJPmzmY5Zdz2MDCagp1Yb4il5oGO6WDeL5JfKfgCTwE4d1+APUwq8g == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheefgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefvufgjfhfhfffkgggtsehttdertddttddtnecuhfhrohhmpeffrghvihguucfg ughmohhnughsohhnuceouggrvhhiugdrvggumhhonhgushhonhesohhrrggtlhgvrdgtoh hmqeenucggtffrrghtthgvrhhnpeegtdegheevhfegieekfffhledtjedugeehffegvdev feffheeliefhkeevfeejfeenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepuggrvhhiugdrvggu mhhonhgushhonhesohhrrggtlhgvrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Jul 2021 09:48:39 -0400 (EDT) Received: from localhost (disaster-area.hh.sledj.net [local]) by disaster-area.hh.sledj.net (OpenSMTPD) with ESMTPA id bb8cfb13; Thu, 29 Jul 2021 13:48:38 +0000 (UTC) To: Sean Christopherson Cc: David Matlack , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Thomas Gleixner , Borislav Petkov , Vitaly Kuznetsov , Joerg Roedel , Ingo Molnar , Wanpeng Li , Jim Mattson , "H. Peter Anvin" , Paolo Bonzini , x86@kernel.org, Joao Martins Subject: Re: [PATCH 2/2] KVM: x86: On emulation failure, convey the exit reason to userspace In-Reply-To: References: <20210628173152.2062988-1-david.edmondson@oracle.com> <20210628173152.2062988-3-david.edmondson@oracle.com> From: David Edmondson Date: Thu, 29 Jul 2021 14:48:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, 2021-07-09 at 21:58:12 GMT, Sean Christopherson wrote: > On Fri, Jul 02, 2021, David Edmondson wrote: >> On Wednesday, 2021-06-30 at 16:48:42 UTC, David Matlack wrote: >> >> > On Mon, Jun 28, 2021 at 06:31:52PM +0100, David Edmondson wrote: >> >> if (!is_guest_mode(vcpu) && static_call(kvm_x86_get_cpl)(vcpu) == 0) { >> >> - vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR; >> >> - vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION; >> >> - vcpu->run->internal.ndata = 0; >> >> + prepare_emulation_failure_exit( >> >> + vcpu, KVM_INTERNAL_ERROR_EMULATION_FLAG_EXIT_REASON); >> > >> > Should kvm_task_switch and kvm_handle_memory_failure also be updated >> > like this? >> >> Will do in v2. >> >> sgx_handle_emulation_failure() seems like an existing user of >> KVM_INTERNAL_ERROR_EMULATION that doesn't follow the new protocol (use >> the emulation_failure part of the union). >> >> Sean: If I add another flag for this case, what is the existing >> user-level consumer? > > Doh, the SGX case should have been updated as part of commit c88339d88b0a ("kvm: > x86: Allow userspace to handle emulation errors"). The easiest fix for SGX would > be to zero out 'flags', bump ndata, and shift the existing field usage. That > would resolve the existing problem of the address being misinterpreted as flags, > and would play nice _if_ additional flags are added. I'll send a patch for that. > > [...] > > Which brings me back to adding another flag when dumping the exit reason. Unless > there is a concrete use case for programmatically taking action in reponse to > failed emulation, e.g. attemping emulation in userspace using insn_bytes+insn_size, > I think we should not add a flag and instead dump info for debug/triage purposes > without committing to an ABI. I.e. define the ABI such that KVM can dump > arbitrary info in the unused portions of data[]. https://lore.kernel.org/r/20210729133931.1129696-1-david.edmondson@oracle.com includes both of these suggestions.