Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp6112222pxv; Thu, 29 Jul 2021 06:51:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJziLXxntfWskeGOruS5AdXbwnAIQjIodt7ZczJFH0kGsXnFsnZiHTWekTr6Pqh1zuRgeWIi X-Received: by 2002:a05:6e02:1d8a:: with SMTP id h10mr3810093ila.20.1627566660112; Thu, 29 Jul 2021 06:51:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627566660; cv=none; d=google.com; s=arc-20160816; b=gvATEd6Y6awsCOxC/NksqqGMrwJzMnljphHArZVdBJPyPtnUMQ0vSeFCAElK7Z3mMp ENWiS8/ZudOS6zCiPlyAQ3RUMtGveTTvfuG5JCQyfC0pVaVDi4Ruk4h6oxODgFJK5rJv 0PiIlNJ5892Fh+nIUjuIVzl6h1mRTiXjtoHusEnSV73i/Ie7vsg+OkqZMef6OdSBtnCI j0pR5yH9rMmhZkrllgH3UchHgII2GGJwizj6tnlJY+pPx/DhknnYeitq50c7vUIEPDom H/leQnc7RWJt89lgHX/YsoiKXbICyd61s7bM05+yxZ4p2NN5qncVy3NSfpLhEeuhDzey yK5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:from:references :in-reply-to:subject:cc:to:dkim-signature; bh=9QPW2TaD5TkdBoSC7awJVUB3Oz/9pHuBCU2Rqw2XRmM=; b=pfzFGM0Wd1AbIhjcakG8Jga142VlMPU+LWghsqFjwhFLFaBzZ8v1DnS240N5dVAaSm x7FVWgWuWGcwcIMDTPgIuQ9mRJzq8wFAQjb0DXs0ZOlgt+d1u4J9PPG/fkopNcOw2oAm 3r+j/1e4iqfXWZck5YJ/O9yU7cWKh41VHYJRSgxtzUhLJcXUrbpTcs70rgVR5Q4JlQUJ tvsaauA+GjiNUagnqF2f2qUj70a5+/c9EeQBOnsuywqejdYILFJCISQrDANvVgWFzxgj GLkE+eJtuIMeAtrgALBBfQEiRGdk6n9YUIpIELXnsKwEFGHQXEU6dmNeb3yk6EIoaGJz R2CQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=UX5PL0C7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r23si3520827iot.18.2021.07.29.06.50.40; Thu, 29 Jul 2021 06:51:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=UX5PL0C7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237846AbhG2Ns5 (ORCPT + 99 others); Thu, 29 Jul 2021 09:48:57 -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.