Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1750385ybb; Thu, 9 Apr 2020 08:20:07 -0700 (PDT) X-Google-Smtp-Source: APiQypI/PG8EmJUW8PCuxDXjFH5Xc5XZ3glZFA6g0r12EkVkihZS2Aqk9pyvqIzZ02c8VRSGxkSp X-Received: by 2002:a37:8845:: with SMTP id k66mr333132qkd.322.1586445607759; Thu, 09 Apr 2020 08:20:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586445607; cv=none; d=google.com; s=arc-20160816; b=gHvkyGkdZcVhk5bxZYS30JuecFTBVEyUo3cOGab3MD0q1mxIM6qEHBouQxNOucPc5a wtUwiDPuIN0ZifBzy5F68qncxy9W+dp1h5OT8toUN68xX8XEFmA2BfZ2PzH22ZjEDNiI kqNQrJyy77jFZO3gn4iY89gUTWQuY1tvhx+W0YxtWGpuJy2xyqluAK9c0+vxI7N2Z8px dzJi4aBT0e96Eb0DzQgTCiBYwlhJiOjz0XAolkl69eHkVnvrimFaBBVhjMWp2UBHPB73 jMk6Cly5sbxvXpeKxaACnFdkxk7nEL56IxsyYz/5xNuDMq8WgQ75PvA4aAAu7g4WO9iG rjgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=Xz/x7+R3F325gRCdi+IZ/dfc0jmeQMCDLQzXTFYiwII=; b=iLY6dghxFheh+433Ubyddn8EfTdgV3+8XqAI/XVqTc30/DVSsgd/RIKO+exT2g5x5o A8E/M8bqzsU9uqDVCJdf1ftjyF4H/DFG4r1rzSdbhpj9q/a6Tvv0Txl1XlmPfC/ERe09 6tJRGJzue+ms7cP4lXyZFfY+nQnatjfASK3/8XNNm20fytsfFNdwhuNcnKv/gsxlwDeS NJgoFzPwHi7G7Yihhj8AXTdC1QAKzrbfbfh768JC//iuNxob8sUSWF24Xv+rT79KrLzr bXFIMKkHcXTYQLjxLxqN3jeaC4Q2wtcuUS5lMVQEP2g0aq23AzGL93hFpVZzmu4Uh2n2 DhEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ILHC9Twd; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e4si7577550qtw.72.2020.04.09.08.19.42; Thu, 09 Apr 2020 08:20:07 -0700 (PDT) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ILHC9Twd; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728102AbgDIPRl (ORCPT + 99 others); Thu, 9 Apr 2020 11:17:41 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:55112 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727919AbgDIPRk (ORCPT ); Thu, 9 Apr 2020 11:17:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586445459; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Xz/x7+R3F325gRCdi+IZ/dfc0jmeQMCDLQzXTFYiwII=; b=ILHC9TwdRqFWUn1c4+2x2uVdf+FZ1IpXuI/ougN8rK9Q+gqm7spcKO9e603l3m8FQClLOx qCdF5jhzmDl04oD0GqWynalKoO7P2HaYAlGUC6gznt9YSpE3mF6LdyyLSec8G9pi05Rs55 h1vV6f/Z0btHZlKvBctnmUFi4foSJbQ= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-301-adyNKr4HNWm3hz2IROT0Xw-1; Thu, 09 Apr 2020 11:17:35 -0400 X-MC-Unique: adyNKr4HNWm3hz2IROT0Xw-1 Received: by mail-wr1-f72.google.com with SMTP id 91so6563868wro.1 for ; Thu, 09 Apr 2020 08:17:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Xz/x7+R3F325gRCdi+IZ/dfc0jmeQMCDLQzXTFYiwII=; b=s2PeakwGugbru4mGnUvTN6DTqfVPrANi7zNkudvOTMr+gpiX7Ctecwqmi9lubfYOkb 6o29PdFtP/cJ8qGAI+yvAOv8tB1LugXYILSMK79M2F5mIyEnOKShVHL+kUaeK3C0XcPb 4K0kWwnKepufumbow0Zw8T6oPfAX8di1hWUiWUTXCzlvDRFL3ugP3yIFeN3TtIJVYf9Y 4a35JvOxj7FGjolMeXq3EFRnwOu+A1P7Gm9ICawM6XmDyF69trVw54dBDu2FnRsK1QmL 3YvAtnbhz1mFqKRYdxqGFLhqwot+ZVcNx9HvKfkAihillMP7cl1CzA/9IqLa3qSfG2AB aJRQ== X-Gm-Message-State: AGi0PuZNXJb45eSZE6TfP32HsBMWct5gBHsVnkbanDPuNYewoS6cK5QU UKDE9XS5R2WQPIwb1NfacoU393Cflv6l7wPT+HiGV/nFMJxyyk/58XglHVhPtobLOa/3f2KU6mC jnagd0sh5wLA22gR7Vol7taD9 X-Received: by 2002:a5d:6183:: with SMTP id j3mr14822044wru.83.1586445454648; Thu, 09 Apr 2020 08:17:34 -0700 (PDT) X-Received: by 2002:a5d:6183:: with SMTP id j3mr14822020wru.83.1586445454436; Thu, 09 Apr 2020 08:17:34 -0700 (PDT) Received: from [192.168.10.150] ([93.56.170.5]) by smtp.gmail.com with ESMTPSA id w15sm31255987wra.25.2020.04.09.08.17.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2020 08:17:33 -0700 (PDT) Subject: Re: [PATCH v2] x86/kvm: Disable KVM_ASYNC_PF_SEND_ALWAYS To: Andy Lutomirski Cc: Andrew Cooper , Andy Lutomirski , Thomas Gleixner , Sean Christopherson , Vivek Goyal , Peter Zijlstra , LKML , X86 ML , kvm list , stable References: <4EB5D96F-F322-45BB-9169-6BF932D413D4@amacapital.net> From: Paolo Bonzini Message-ID: <931f6e6d-ac17-05f9-0605-ac8f89f40b2b@redhat.com> Date: Thu, 9 Apr 2020 17:17:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <4EB5D96F-F322-45BB-9169-6BF932D413D4@amacapital.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/04/20 17:03, Andy Lutomirski wrote: >> No, I think we wouldn't use a paravirt #VE at this point, we would >> use the real thing if available. >> >> It would still be possible to switch from the IST to the main >> kernel stack before writing 0 to the reentrancy word. > > Almost but not quite. We do this for NMI-from-usermode, and it’s > ugly. But we can’t do this for NMI-from-kernel or #VE-from-kernel > because there might not be a kernel stack. Trying to hack around > this won’t be pretty. > > Frankly, I think that we shouldn’t even try to report memory failure > to the guest if it happens with interrupts off. Just kill the guest > cleanly and keep it simple. Or inject an intentionally unrecoverable > IST exception. But it would be nice to use #VE for all host-side page faults, not just for memory failure. So the solution would be the same as for NMIs, duplicating the stack frame and patching the outer handler's stack from the recursive #VE (https://lwn.net/Articles/484932/). It's ugly but it's a known ugliness. Paolo