From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Denis V. Lunev" Subject: Re: [PATCH] kvm:vmx: update secondary controls when disabling APICv Date: Tue, 17 May 2016 08:25:37 +0300 Message-ID: <573AAB51.50709@openvz.org> References: <1463413107-32268-1-git-send-email-rkagan@virtuozzo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list , Paolo Bonzini To: Steve Rutherford , Roman Kagan Return-path: Received: from mail-am1on0123.outbound.protection.outlook.com ([157.56.112.123]:22354 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751757AbcEQFkt (ORCPT ); Tue, 17 May 2016 01:40:49 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 05/16/2016 11:15 PM, Steve Rutherford wrote: > After updating the secondary execution controls, the MSR bitmaps need > to be updated to enable APIC MSR intercepts (i.e. start treating APIC > MSRs as if the guest's APICs are back in xAPIC mode by calling > vmx_set_msr_bitmap, given that updating the execution controls should > disable "virtualize x2APIC mode"). > > The function vmx_set_msr_bitmap needs to look at the state of APICv to > know that "virtualize x2APIC mode" was disabled. > > Also, calling vmx_secondary_exec_control clobbers /all/ dynamic bits > in the secondary controls (including the shadow VMCS bits). Those bits > needs to be respected (ideally this patch should just whack all of the > APICv related secondary execution controls). > > I can put together a patch if you'd like. for the perfect world I will agree. For a real life -Windows does not support x2Apic. OK. We will think on this a bit. May be they will in Win2016.