Received: by 10.223.164.202 with SMTP id h10csp722074wrb; Fri, 10 Nov 2017 13:43:07 -0800 (PST) X-Google-Smtp-Source: AGs4zMZbpsIWk7UQeAQQ+5FPdjQlIx3sCJ0e64UrSaWrSk1jf4xz/FZub+3ppaNj5B+Cid4tfLSo X-Received: by 10.99.173.74 with SMTP id y10mr1621441pgo.107.1510350187133; Fri, 10 Nov 2017 13:43:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510350187; cv=none; d=google.com; s=arc-20160816; b=icZ8xwQfsTPtWQMoR9X0oanKteuwFEgN01qQckn+e9sVFCnnelGntm8oAYTHz060Km ne1cfA0MHynhIdZraUVdFHsB2WUHqLHBBHnsamARBmayVsP6TQ1zqYMtbIL1720PTRzl iL4mVl0WXJ/ZsMzwxMSSXGZe2NCsUM6y7vtd2wIZ9spcJ+UkVpyccjrjyTu8gD2kkXZQ /sohqBgtb9ZKszP9dV/h9ZzSXI1590CRj5wGFns1TZGEWlQHSxDwAnrtFeQ6fxOQEU87 5bMEVhlLsuMOs/PJcn0Kz+frEL5LgHGneCSuJzJCBi1z/V/LA2hSEhFRaHAfphpBHcgz AMsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=YNxDSAJdhrXTrkMoEsFZ3/gmWDo7taxQrirMEk8bUjc=; b=bkLZ7Y1HzBXg/+80UIPTxv/nld2lovV2Z3C9so0bd8PWaRzErrgy/VaNd9s4fsV4rw MGEhxXLArGNvhIh7Vlqh2MdHqNqvV2WSd7/SdkAZ6Wu3G2HplFSFIke9DKWuXS+67bGB 8+0X4vsE9QUxxHB2OQhWrQSYcdmMv4hyD5HfWk4YJhFNXhxKMosja8UtK90tOtzgNszV 1GlUb6DK+gZGhv0LH/n1BtqNeCjZxYfJxuVo41fFD6i1YJ/NvZIXjcQqc9PrA4DKzovZ xRtHmh+pK7IliRNHZeTuQukMRjzfrYMBTch8gwO9xSBAemSVCH4oapLD6bv/QtHHzK7K 6NSg== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c2si9992927pli.451.2017.11.10.13.42.55; Fri, 10 Nov 2017 13:43:07 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754328AbdKJVmT (ORCPT + 83 others); Fri, 10 Nov 2017 16:42:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41056 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753594AbdKJVmS (ORCPT ); Fri, 10 Nov 2017 16:42:18 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3B29C61467; Fri, 10 Nov 2017 21:42:18 +0000 (UTC) Received: from flask (unknown [10.43.2.80]) by smtp.corp.redhat.com (Postfix) with SMTP id D911A5D992; Fri, 10 Nov 2017 21:42:15 +0000 (UTC) Received: by flask (sSMTP sendmail emulation); Fri, 10 Nov 2017 22:42:15 +0100 Date: Fri, 10 Nov 2017 22:42:15 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, yfu@redhat.com, Eduardo Habkost , stable@vger.kernel.org Subject: Re: [PATCH] KVM: x86: inject exceptions produced by x86_decode_insn Message-ID: <20171110214214.GI2189@flask> References: <1510307378-97452-1-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1510307378-97452-1-git-send-email-pbonzini@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 10 Nov 2017 21:42:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-11-10 10:49+0100, Paolo Bonzini: > Sometimes, a processor might execute an instruction while another > processor is updating the page tables for that instruction's code page, > but before the TLB shootdown completes. The interesting case happens > if the page is in the TLB. > > In general, the processor will succeed in executing the instruction and > nothing bad happens. However, what if the instruction is an MMIO access? > If *that* happens, KVM invokes the emulator, and the emulator gets the > updated page tables. If the update side had marked the code page as non > present, the page table walk then will fail and so will x86_decode_insn. > > Unfortunately, even though kvm_fetch_guest_virt is correctly returning > X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as > a fatal error if the instruction cannot simply be reexecuted (as is the > case for MMIO). And this in fact happened sometimes when rebooting > Windows 2012r2 guests. Just checking ctxt->have_exception and injecting > the exception if true is enough to fix the case. > > Thanks to Eduardo Habkost for helping in the debugging of this issue. > > Reported-by: Yanan Fu > Cc: Eduardo Habkost > Cc: stable@vger.kernel.org > Signed-off-by: Paolo Bonzini > --- Applied, thanks. From 1583672192246103487@xxx Fri Nov 10 09:51:35 +0000 2017 X-GM-THRID: 1583672192246103487 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread