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 4C30BC433F5 for ; Fri, 15 Apr 2022 14:40:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243255AbiDOOnA (ORCPT ); Fri, 15 Apr 2022 10:43:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354522AbiDOOmY (ORCPT ); Fri, 15 Apr 2022 10:42:24 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 443121A3A3 for ; Fri, 15 Apr 2022 07:39:53 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id mm4-20020a17090b358400b001cb93d8b137so11954261pjb.2 for ; Fri, 15 Apr 2022 07:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1MnvIUTCnDUhW/MEcdcS6a3sJGad6CD8T1rW5EsHJho=; b=ERP9pfWyY6alNYGhD48Zx2tVKN4LFJdrCOxLl3DgrkY8Uoebc+mqvBHsJ0wNr0H91I iJlOikU9SuosDX3fezHVHtW/9TaCkdUJFWtppyap9e4ThipVFTS1UYRIF1XL63AJQ6+b N5kAbODQQoSrY0Igts9Vv2ptmwOLZ/rHvl13UotTUsYZoRv9hrSOSlg8l8CjvbdPj6Hk wzuOPlYgSwylW5rt+oE4SaY0RAhCm/vIuZKUTC90h3m1Wcg9a9tatSQwi3gEFM83zBr5 oU1XixgbbeyUZH0/n//qIs8FGfjWlgqM3+cFfQ037bArt8Wct10TDXW2gRoAlx/opM55 PLrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1MnvIUTCnDUhW/MEcdcS6a3sJGad6CD8T1rW5EsHJho=; b=g+PEonteEC0YjmaFt5RHQUNXI7pWDyv1nmm7IJiKrxNFWimuoRJDIRUtdt/2ANqG7p zQPLDjCj+uxph9A5zyjp3SryeVbLd04Xkwh4/x1EtF1ggvxls7TNfubNdJGy57XQ605F D6hr1dHrlHg08AtYAdezpSHpe6aYsqHx4wzMqT4s8I/MVxltthH6e/75RTenep0Huyyg 2JPd5CU5I8eubYVTGDGID08a8FgM2qcsWd1VllsEJ/unStG5Mai5CyN+SZa4oQaKWDWu d1N4YH43ZQJXQFEp6VRi1MyeOg63yaXNbobDiBzpXHNtGMNiNYuR4TXDJeaEwa5oSg8i SzzQ== X-Gm-Message-State: AOAM530WnCrEQ0tuc19P3uixKBpYR5SLgJWbPJVJ4RdF/gs12UplG2J8 Te1skycdqMO+NcXtijkutkzfBg== X-Google-Smtp-Source: ABdhPJxiWSn2FG95SA76dSXfh63IIlA1JbMOT4SlEzlrg7n8lbIUkNG860vEUcouEZ8VKy45Cf5TOQ== X-Received: by 2002:a17:90a:6501:b0:1ca:a7df:695c with SMTP id i1-20020a17090a650100b001caa7df695cmr4587060pjj.152.1650033592553; Fri, 15 Apr 2022 07:39:52 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id k4-20020a17090a3e8400b001cd37f6c0b7sm4868835pjc.46.2022.04.15.07.39.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 07:39:51 -0700 (PDT) Date: Fri, 15 Apr 2022 14:39:48 +0000 From: Sean Christopherson To: Zeng Guang Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, Dave Hansen , Tony Luck , Kan Liang , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Kim Phillips , Jarkko Sakkinen , Jethro Beekman , Kai Huang , x86@kernel.org, linux-kernel@vger.kernel.org, Robert Hu , Gao Chao , Maxim Levitsky Subject: Re: [PATCH v8 6/9] KVM: x86: lapic: don't allow to change APIC ID unconditionally Message-ID: References: <20220411090447.5928-1-guang.zeng@intel.com> <20220411090447.5928-7-guang.zeng@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220411090447.5928-7-guang.zeng@intel.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Apr 11, 2022, Zeng Guang wrote: > From: Maxim Levitsky > > No normal guest has any reason to change physical APIC IDs, and > allowing this introduces bugs into APIC acceleration code. > > And Intel recent hardware just ignores writes to APIC_ID in > xAPIC mode. More background can be found at: > https://lore.kernel.org/lkml/Yfw5ddGNOnDqxMLs@google.com/ > > Looks there is no much value to support writable xAPIC ID in > guest except supporting some old and crazy use cases which > probably would fail on real hardware. So, make xAPIC ID > read-only for KVM guests. AFAIK, the plan is to add a capability to let userspace opt-in to a fully read-only APIC ID[*], but I haven't seen patches... Maxim? [*] https://lore.kernel.org/all/c903e82ed2a1e98f66910c35b5aabdcf56e08e72.camel@redhat.com