Received: by 10.223.185.116 with SMTP id b49csp761930wrg; Sat, 10 Feb 2018 19:20:47 -0800 (PST) X-Google-Smtp-Source: AH8x224mgGf2UIpSc+cQ+qH1yZSLubBnREyz24W6w4pd3wYGNnEhr4HvjKlVDOEVo3U/T1p8gt5m X-Received: by 2002:a17:902:7c18:: with SMTP id x24-v6mr6935485pll.432.1518319247326; Sat, 10 Feb 2018 19:20:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518319247; cv=none; d=google.com; s=arc-20160816; b=BG83jjiJNeRPY0xnrF/7YKBxQwFf8Qajxzv/SJzuxfG/IQQH/zRdFrLag8yRUvOijh A1cNJ8bDV5IfX70kmPGDYi6JaC0p0DiKQn5a2k0eun8DVtKJxEs73hYQ1LzODFuS5XnN UXsnZbkYgQY9jY+LqDn+azx5mrLBX3dD9+1en6EuloHCMNdiHR7wReRPnsiVnxDjlWKI rdC/KNSYJdcH4Tb7Tj69DPbQ7wletdKB89Qqgs+bDc423SFCbZZ9USryzy6Ai8v5Li1x cw1FxDgRk1Kd18KbkL0k0ue63MGjNDAKIMGky8AQ+OQRlQQkpvZCrOQ/BEAjjzitKh/G 9KFQ== 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 :arc-authentication-results; bh=EPBaS2IP7r8xQ6gSjREH/5fIIxSkme6ZKrqrUH73PKw=; b=ipzgOqyeQvGUPGeC8lmI9eBaEau4EaCOqFOeMuY2SpzDFbth8smB2qrF3cEH1+LuY7 KzvXiJdtzkNkmNo+VVUY5UvWcxeC8vgBUJqjhJd7dZus1E3KMPWlIcbetZzDy9CMAqk7 rcLX9W9CMJgQoW6YDXJr3G7QlFjDJc8WcCkPZ50OFaiIaO4qCbXHVGDIW1vP/sTPiCV8 G8VknIa5AaoP7UoVwxXBG4pXc646GPmNntHcZnDRJlrYdc2MYotF0c9MaLTY6klSDIIN JRpfZWPhkkymnnsEfcZUS+LovAynZXr53rzQb33FVjvafPmaRuh+u6izfjPm2NXnEwvP sbIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XT2KZHY2; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a16si4214373pfi.109.2018.02.10.19.20.33; Sat, 10 Feb 2018 19:20:47 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XT2KZHY2; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752401AbeBKDT6 (ORCPT + 99 others); Sat, 10 Feb 2018 22:19:58 -0500 Received: from mail-pl0-f65.google.com ([209.85.160.65]:32981 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752285AbeBKDTz (ORCPT ); Sat, 10 Feb 2018 22:19:55 -0500 Received: by mail-pl0-f65.google.com with SMTP id t4so3352958plo.0; Sat, 10 Feb 2018 19:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EPBaS2IP7r8xQ6gSjREH/5fIIxSkme6ZKrqrUH73PKw=; b=XT2KZHY2XNV/QTGkrKlMkocaFtkGQV/GY3lrP2bdRBvteY+s0zUsT4dT1eYtV3b73z WkjFp3KXQkMNkZjC75FzNg1hVVlDwPWyy08Q4eU0glg0pxuRbiYndty2hMo024p9Hdq3 zpTu5XmWQkjyjfB5aplsUMyi/AGUGs2CdeP3BAxVXH+pWkFjEQi5BpjlK6dFKaSgTuDR 4AE/TyyxEYyKeDmA9agvwIs6R3bzdpzOPVLUh2c59JvRTk2cJhewACpiPEvg2xE4MIgn DiggstRzeb9jDp7PdMGf/eCxHKRJDsxZI1LHPQL7i/AFe/3DxuL9zdQq06Mrvys2s+3R Bsjg== 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=EPBaS2IP7r8xQ6gSjREH/5fIIxSkme6ZKrqrUH73PKw=; b=XJftre7u3o8np3aqpGIURumyn80xdDR866/cbLSIx3KLEuOpQRlSVWm0hi7GLjuVVV rgSKptKATDDhKqJOP1aCv0IFmMsNhVSQaCwmqrMlrNYNTKoscktcvkPM7EHsHxnQWmOe vJcqC4A05jz8h0CS/HpOWlFpvuxjNurjLrq/r0XT7ipx1z/SyKeYCfnUrF5W0pWM+KWY WD4jJK+e/kErbiHEO7mgPqMFHWj/2IFwy4Z0Xv+eKinG737H/XIRc9U3rKV8DLE+EKja FdSN7MfwE1IOYOmv3wBW8FxvqylJDeHyrzPac26FWzQQWso45gHK8duPnIxJ4MaEJoT1 /mfQ== X-Gm-Message-State: APf1xPA4P19XDKYAz5oI394TjdR0+RvU7p84bQqtBr9t76Iz/lnsUx9n rji2xnlKVmwef1hoRY2871F40hGK X-Received: by 2002:a17:902:a5c5:: with SMTP id t5-v6mr7168516plq.160.1518319194682; Sat, 10 Feb 2018 19:19:54 -0800 (PST) Received: from eric.tencent.com ([203.205.141.35]) by smtp.gmail.com with ESMTPSA id k3sm13260958pff.41.2018.02.10.19.19.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Feb 2018 19:19:54 -0800 (PST) Subject: Re: [PATCH] KVM: X86: Fix SMRAM accessing even if VM is shutdown To: Paolo Bonzini , Wanpeng Li , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Dmitry Vyukov References: <1517984706-47244-1-git-send-email-wanpengli@tencent.com> <233cfca3-971e-c3c2-f0fe-b50dd69d2546@redhat.com> <5664ca7f-f391-0301-3a0d-666b73f17b15@redhat.com> <9034fe13-26c4-ee72-5b94-19aa8fc11efc@gmail.com> <0aedd0e5-f5eb-54d8-6f77-e7a12c65fed5@redhat.com> From: Xiao Guangrong Message-ID: <63c3626c-e64d-aa56-3935-be046d731232@gmail.com> Date: Sun, 11 Feb 2018 11:20:23 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <0aedd0e5-f5eb-54d8-6f77-e7a12c65fed5@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/09/2018 08:42 PM, Paolo Bonzini wrote: > On 09/02/2018 04:22, Xiao Guangrong wrote: >>> >> >> That is a good question... :) >> >> This case (with KVM_MEMSLOT_INVALID is set) can be easily constructed, >> userspace should avoid this case by itself (avoiding vCPU accessing the >> memslot which is being updated). If it happens, it's a operation issue >> rather than INTERNAL ERROR. >> >> Maybe treat it as MMIO accessing and return to userspace with MMIO_EXIT >> is a better solution... > > Yeah, that's what emulation would do (except if it's an instruction > fetch, which will cause emulation to fail). I think it's a bug in the > non-EPT #PF case that we return with -EFAULT. Wanpeng, could you please do it? :)