Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp689230pxx; Wed, 28 Oct 2020 14:35:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy5IOehw7hCOS4f7UbE+eC+UQLZS5ulXyHPvV4qTh540z8JSDGLTbpEmshXI0g672J+Azf0 X-Received: by 2002:a17:906:eb59:: with SMTP id mc25mr1093098ejb.34.1603920903651; Wed, 28 Oct 2020 14:35:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603920903; cv=none; d=google.com; s=arc-20160816; b=dSikwG5khoHmq9V/mgY0RosizdH85LJb4IExnFwgM9SPRsuDQHx5GuTB1hBDxdjNih 4rdYfR9QUVlNUIOSXLwwLoOXKDT9lw6irU8BsqKw+fes0k11rDdop95xWuxdxTZjEl47 MER1LnhxqcpR36raM3IB7fZgve850sUCzFe/coERQ9NJt1UE102KGx/Rr5BmAKtFTVZf p/uoq6y/iIMSp0Ysd1qauq+3U7xsb6QSUB6TBW1Mje/MhTCUcTrsemW73ldKq8OUdky8 LNoGbQ72lW2KxVDc4lVRqfs86FKQZEBKO4yZm1PAeg6IN/sqLZVyTpdh+s/Yd0ZLA++2 Buzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature; bh=2jw2I23iwBY99w0/c3MnXeZh6i5zZp8WwMZqR6Jv0Uw=; b=OXgRVrUXUdtOV/pHCorlv3HV52NspGSYzYX9XM0ZmfTzL0zi29NFCZzWdVuLY8flxu 6+C3YLC89gvuf3C0t8FIKIxVVGNCD8XLEOZESfdv8KD4NZ5T9jmtBoaZOD+5Z2666M4e Hpp+xNwAY4LG4xYlU7rdIcCZWGuB+KTdQwfFX5WxH9dXwNqcNkZzlmsuXSXvQtwbZfSA q/bhzptPCrOAz+kVUnIagL/OnKAB6ggAFHxqJ4gT8a91f1oP7HCDXv0l0LWFHqYht6zW ZC1Ankicy6ne8j6d2SSdvoR8rcLB+DPtWbIBPSgTuQBz+/V1B/q7vC6OTrTBnDT5e83r t9yg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eUOElFqm; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p3si321973ejw.731.2020.10.28.14.34.40; Wed, 28 Oct 2020 14:35:03 -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=@redhat.com header.s=mimecast20190719 header.b=eUOElFqm; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S372953AbgJ0Ubh (ORCPT + 99 others); Tue, 27 Oct 2020 16:31:37 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:36465 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S372939AbgJ0Ubg (ORCPT ); Tue, 27 Oct 2020 16:31:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603830695; 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=2jw2I23iwBY99w0/c3MnXeZh6i5zZp8WwMZqR6Jv0Uw=; b=eUOElFqm2VeCd5um4jI8pbtsQuynjgO/DwyV9U5+fTeEzErRgZVGJb1tL2Au8lsanRu6ji R7lfi5fJ7SjUb82hJuJH9ZlEpc8MMPm5+ox1s5u6NKwnlsZlGuE3BDnIQHHnra9yRYnR1W lNhu2BIEbVEMLdSBrATmc1g1v73vvJo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-132-pEKfTLzFM5CZIQZ1fdHpcA-1; Tue, 27 Oct 2020 16:31:33 -0400 X-MC-Unique: pEKfTLzFM5CZIQZ1fdHpcA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DB33D1868434; Tue, 27 Oct 2020 20:31:31 +0000 (UTC) Received: from ovpn-66-71.rdu2.redhat.com (ovpn-66-71.rdu2.redhat.com [10.10.66.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 00B8F60C07; Tue, 27 Oct 2020 20:31:27 +0000 (UTC) Message-ID: Subject: Re: [PATCH v6 2/4] KVM: x86: report negative values from wrmsr emulation to userspace From: Qian Cai To: Maxim Levitsky , kvm@vger.kernel.org Cc: "H. Peter Anvin" , Ingo Molnar , Borislav Petkov , Vitaly Kuznetsov , Sean Christopherson , Joerg Roedel , Paolo Bonzini , Wanpeng Li , Thomas Gleixner , linux-kernel@vger.kernel.org, Jim Mattson , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Linus Torvalds Date: Tue, 27 Oct 2020 16:31:26 -0400 In-Reply-To: <849d7acb00b3dadc3fc7db1e574c03dc74a06270.camel@redhat.com> References: <20200922211025.175547-1-mlevitsk@redhat.com> <20200922211025.175547-3-mlevitsk@redhat.com> <849d7acb00b3dadc3fc7db1e574c03dc74a06270.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2020-10-26 at 15:40 -0400, Qian Cai wrote: > On Wed, 2020-09-23 at 00:10 +0300, Maxim Levitsky wrote: > > This will allow the KVM to report such errors (e.g -ENOMEM) > > to the userspace. > > > > Signed-off-by: Maxim Levitsky > > Reverting this and its dependency: > > 72f211ecaa80 KVM: x86: allow kvm_x86_ops.set_efer to return an error value > > on the top of linux-next (they have also unfortunately merged into the > mainline > at the same time) fixed an issue that a simple Intel KVM guest is unable to > boot > below. So I debug this a bit more. This also breaks nested virt (VMX). We have here: [ 345.504403] kvm [1491]: vcpu0 unhandled rdmsr: 0x4e data 0x0 [ 345.758560] kvm [1491]: vcpu0 unhandled rdmsr: 0x1c9 data 0x0 [ 345.758594] kvm [1491]: vcpu0 unhandled rdmsr: 0x1a6 data 0x0 [ 345.758619] kvm [1491]: vcpu0 unhandled rdmsr: 0x1a7 data 0x0 [ 345.758644] kvm [1491]: vcpu0 unhandled rdmsr: 0x3f6 data 0x0 [ 345.951601] kvm [1493]: vcpu1 unhandled rdmsr: 0x4e data 0x0 [ 351.857036] kvm [1493]: vcpu1 unhandled wrmsr: 0xc90 data 0xfffff After this commit, -ENOENT is returned to vcpu_enter_guest() causes the userspace to abort. kvm_msr_ignored_check() kvm_set_msr() kvm_emulate_wrmsr() vmx_handle_exit() vcpu_enter_guest() Something like below will unbreak the userspace, but does anyone has a better idea? --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1748,7 +1748,7 @@ int kvm_emulate_wrmsr(struct kvm_vcpu *vcpu) return 0; /* Signal all other negative errors to userspace */ - if (r < 0) + if (r < 0 && r != -ENOENT) return r; /* MSR write failed? Inject a #GP */