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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EF5AC433F5 for ; Wed, 23 Feb 2022 05:59:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238110AbiBWGAT (ORCPT ); Wed, 23 Feb 2022 01:00:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55452 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232274AbiBWGAP (ORCPT ); Wed, 23 Feb 2022 01:00:15 -0500 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA92D3B00C; Tue, 22 Feb 2022 21:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645595988; x=1677131988; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=NIratgGYOhkpACukr35jSYKDkM0v76qmlkK/PhGjAS8=; b=XVBj3nLxznNDiHi4XIYkTH+HXpjHe5z+3Xah9hLcrbQA84PEqeE6wCqm bNyCLWvpBeB/iGhMqvcLUwcnSYIflSVOZV7D9WiYKZufoUbKusRQ9PV5l WIIMXU6pu2jlMnLt8LtSS4dWt5EpdmCWpzCfla/LPrz9f26ZeQrMMVt+S wd9zhSaU9c1yUlmttEtsTa3iRfNodAIwxr6domBz/2rMzhDtsRonYORpj uXyNLXSIWRFOIO/jQui7/xjp68DNvdbncz19FMQIEg1Ouk2jO6Qiwo5pG iw3idhSdJvzmYSx1f86vAbULVgv752vMJNKXWbsV7+dpAtVSQ4pgRUNI+ Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10266"; a="235401098" X-IronPort-AV: E=Sophos;i="5.88,390,1635231600"; d="scan'208";a="235401098" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2022 21:59:48 -0800 X-IronPort-AV: E=Sophos;i="5.88,390,1635231600"; d="scan'208";a="491071664" Received: from gao-cwp.sh.intel.com (HELO gao-cwp) ([10.239.159.105]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2022 21:59:42 -0800 Date: Wed, 23 Feb 2022 14:10:38 +0800 From: Chao Gao To: Sean Christopherson , Maxim Levitsky Cc: Maxim Levitsky , Zeng Guang , Tom Lendacky , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , "kvm@vger.kernel.org" , Dave Hansen , "Luck, Tony" , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , "Huang, Kai" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Hu, Robert" Subject: Re: [PATCH v5 7/8] KVM: VMX: Update PID-pointer table entry when APIC ID is changed Message-ID: <20220223061037.GA21263@gao-cwp> References: <640e82f3-489d-60af-1d31-25096bef1a46@amd.com> <4eee5de5-ab76-7094-17aa-adc552032ba0@intel.com> <20220110074523.GA18434@gao-cwp> <1ff69ed503faa4c5df3ad1b5abe8979d570ef2b8.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 03, 2022 at 08:22:13PM +0000, Sean Christopherson wrote: >i.e. ACPI_NUMA gets priority and thus amd_numa_init() will never be reached if >the NUMA topology is enumerated in the ACPI tables. Furthermore, the VMM would >have to actually emulate an old AMD northbridge, which is also extremely unlikely. > >The odds of breaking a guest are further diminised given that KVM doesn't emulate >the xAPIC ID => x2APIC ID hilarity on AMD CPUs and no one has complained. > >So, rather than tie this to IPI virtualization, I think we should either make >the xAPIC ID read-only across the board, We will go this way and defer the introduction of "xapic_id_writable" to the emergence of the "crazy" use case. Levitsky, we plan to revise your patch 13 "[PATCH RESEND 13/30] KVM: x86: lapic: don't allow to change APIC ID when apic acceleration is enabled" to make xAPIC ID read-only regardless of APICv/AVIC and include it into IPI virtualization series (to eliminate the dependency on your AVIC series). Is it fine with you? And does this patch 13 depend on other patches in your fixes? >or if we want to hedge in case someone >has a crazy use case, make the xAPIC ID read-only by default, add a module param >to let userspace opt-in to a writable xAPIC ID, and report x2APIC and APICv as >unsupported if the xAPIC ID is writable. E.g. rougly this, plus your AVIC patches >if we want to hedge.