Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp6094085ybv; Wed, 12 Feb 2020 06:00:07 -0800 (PST) X-Google-Smtp-Source: APXvYqwY9CpE3gWyvrPbsVaM3irYIIEbogOa36gKqoRY3FJHdk9aIy+8iUpKKmiEcdQZyzUqM9QD X-Received: by 2002:a54:4816:: with SMTP id j22mr6270357oij.179.1581516006931; Wed, 12 Feb 2020 06:00:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581516006; cv=none; d=google.com; s=arc-20160816; b=OPdy8zXkP37961yLg30U2XHeE7iXCGcXpb4wbHVXn9yPvvZS/UvVsfrqLgUN/Yvq1D Wr+ZWIFvnx12boQRuh8XqHR9t4My2vp5DzR++sIBZqXhsoby1HibqnQo0lnS+PqlnA9+ yocp+R+S2cusPftVBAK4DPRzy//ILmYSDZk8qztrTnyoFIe3YTtPSFurY5uO8trMwdLX bTeYxXWa1khyyFBgN7uHnqBuzQwOBkI8SSJskP4mHqD5b3ze8/DkRdLY9sFZb0scjMOU NooSyXGPQEzFCKnQN4zQUDMc89rDL35Ju3dVES2Ccu2KruRdEpzJRCjcQ2c3Ip6U0mUE VxIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=o6yK72XBEO/WPKdQyYJc+m/IaJq/ShTRRKnH1xS9Eug=; b=HNYCU49XYwSNs0AuWvCDnFagmmHbqv7SAFEeiMPP6MRriECL1h4RvETixOYBz8CMPy aPvLpef+wXqHnLaK+jnfMwrb6DhQutgF0ltgE0Zqvr9tKSZJN/jdiHaiWYjK66reQbpc /bMtdBiathFjdmnVkMafJVhW8i9uwLRflfN7FteDZMa2grVZUQZwYkUosDUri0waXymx IivTtUuZxo652zA70vnw5R0MzhSmBhIWDpYeX1uEDW1lEVwPNRRf5EjNjaEzfZLhUh1w mDQIS8mKJNQRwzxXPCs/9ygQ2vNic+OCaPeiXcGx3EKfPzthh9SxCi2FHXYz+6J25NBH g/ig== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w7si253268otq.250.2020.02.12.05.59.54; Wed, 12 Feb 2020 06:00:06 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728228AbgBLN7o (ORCPT + 99 others); Wed, 12 Feb 2020 08:59:44 -0500 Received: from 8bytes.org ([81.169.241.247]:53960 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725887AbgBLN7o (ORCPT ); Wed, 12 Feb 2020 08:59:44 -0500 Received: by theia.8bytes.org (Postfix, from userid 1000) id BE6EC20E; Wed, 12 Feb 2020 14:59:42 +0100 (CET) Date: Wed, 12 Feb 2020 14:59:34 +0100 From: Joerg Roedel To: Andy Lutomirski Cc: x86@kernel.org, hpa@zytor.com, Andy Lutomirski , Dave Hansen , Peter Zijlstra , Thomas Hellstrom , Jiri Slaby , Dan Williams , Tom Lendacky , Juergen Gross , Kees Cook , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, Joerg Roedel Subject: Re: [RFC PATCH 00/62] Linux as SEV-ES Guest Support Message-ID: <20200212135934.GL20066@8bytes.org> References: <20200211135256.24617-1-joro@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 11, 2020 at 07:48:12PM -0800, Andy Lutomirski wrote: > > > > On Feb 11, 2020, at 5:53 AM, Joerg Roedel wrote: > > > > > > > * Putting some NMI-load on the guest will make it crash usually > > within a minute > > Suppose you do CPUID or some MMIO and get #VC. You fill in the GHCB to > ask for help. Some time between when you start filling it out and when > you do VMGEXIT, you get NMI. If the NMI does its own GHCB access [0], > it will clobber the outer #VC’a state, resulting in a failure when > VMGEXIT happens. There’s a related failure mode if the NMI is after > the VMGEXIT but before the result is read. > > I suspect you can fix this by saving the GHCB at the beginning of > do_nmi and restoring it at the end. This has the major caveat that it > will not work if do_nmi comes from user mode and schedules, but I > don’t believe this can happen. > > [0] Due to the NMI_COMPLETE catastrophe, there is a 100% chance that > this happens. Very true, thank you! You probably saved me a few hours of debugging this further :) I will implement better handling for nested #VC exceptions, which hopefully solves the NMI crashes. Thanks again, Joerg