From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D04CC04A6B for ; Wed, 8 May 2019 16:29:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E86B3208C3 for ; Wed, 8 May 2019 16:29:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727535AbfEHQ3J convert rfc822-to-8bit (ORCPT ); Wed, 8 May 2019 12:29:09 -0400 Received: from mail.wl.linuxfoundation.org ([198.145.29.98]:40100 "EHLO mail.wl.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727150AbfEHQ3J (ORCPT ); Wed, 8 May 2019 12:29:09 -0400 Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9B7C328A09 for ; Wed, 8 May 2019 16:29:08 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8FF8E284F9; Wed, 8 May 2019 16:29:08 +0000 (UTC) From: bugzilla-daemon@bugzilla.kernel.org To: kvm@vger.kernel.org Subject: [Bug 203543] Starting with kernel 5.1.0-rc6, kvm_intel can no longer be loaded in nested kvm/guests Date: Wed, 08 May 2019 16:29:07 +0000 X-Bugzilla-Reason: None X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: AssignedTo virtualization_kvm@kernel-bugs.osdl.org X-Bugzilla-Product: Virtualization X-Bugzilla-Component: kvm X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: blocking X-Bugzilla-Who: sean.j.christopherson@intel.com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: virtualization_kvm@kernel-bugs.osdl.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Bugzilla-URL: https://bugzilla.kernel.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Virus-Scanned: ClamAV using ClamSMTP Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org https://bugzilla.kernel.org/show_bug.cgi?id=203543 --- Comment #7 from Sean Christopherson (sean.j.christopherson@intel.com) --- On Wed, May 08, 2019 at 07:00:54PM +0300, Liran Alon wrote: > +Paolo > > What are your thoughts on this? What is the reason that KVM relies on > CPU_BASED_RDPMC_EXITING to be exposed from underlying CPU? How is it critical > for it’s functionality? If it’s because we want to make sure that we hide > host PMCs, we should condition this to be a min requirement of kvm_intel only > in case underlying CPU exposes PMU to begin with. Do you agree? If yes, I > can create the patch to fix this. I sent a revert of the change to hide CPU_BASED_RDPMC_EXITING, KVM's previous behavior is correct. The RDPMC instruction was introduced long before Architctural Perf Mon and so the existence of the exiting control is dependent only on the instruction, e.g. P4 (Prescott), Core (Yonah) and Core2 (Merom) all support VMX and RDPMC with non-archictectural perf mon capabilities. The KVM unit test first execute RDPMC with interception disabled in the unit test host, i.e. the #GP is the correct architectural behavior and needs to be handled by the unit test. The most robust fix would be to eat any #GP on RDPMC in the unit test, though it's likely much simpler to only execute RDPMC with interception disabled if arch perf mon is supported. -- You are receiving this mail because: You are watching the assignee of the bug.