Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2110780pxb; Wed, 9 Feb 2022 11:04:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJzzRni0KPinAkDqsXH7Xg920lWMeT5vnVJ/LDeghdfFdc+i/E5CWqSDXoYIS8UOFkNaSe2O X-Received: by 2002:a17:90a:e7c8:: with SMTP id kb8mr4137874pjb.228.1644433453635; Wed, 09 Feb 2022 11:04:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644433453; cv=none; d=google.com; s=arc-20160816; b=GH/lwXifQRphJRzA0M7VjgvNR1q1r+2DfYe/djDfLMQ/JAYYx5uLQNX6y9yY3+y7Dw kiqUvvQvPtv90PmHVDazjWFWAu7UA3yWt4f5Pn+uymOK3JKf5CThl6t8eC93pqxC03Q1 HaOPmtQhJ+7JUv40uZEAIFQgwBqxg8n/5i88LcJO5RFsn+E7nv5Ca/br5nzhDXCIxrVC w2KnTTPbnEUsqKS6XgeYORG9P08Sp6r45Y/dh1b3qLYcXhCOqU1WNPEEGRZ5TabgQzh1 HS0eYQrfOdbhQXiZFHjmL9vgjtah/LYl+TFGd+DkJIlWXije66L99Vtfmcnuxg+Z6O0s Klbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=bn+NqQc+WkBL0eCTGvSDZFvqDNmAbZwHfh1WyoVIqEU=; b=cbrDGSUIG6/3XK7+Ohi8hU2qGiOjs6p4mq/wY6vm2lK11veeB4MgL0rLwuj1oJL2qn sB/ruiimj7ZYZGMBbaVVl8V4jmNMwqVwO5UbsMH2/grMe6PjlZlK3yxOv8QfXaMyCTid GsJrQ1TtUnc5Lj6ovRziu3qkqn5N3xmuzNHOt8dNCRDEGtsxRVhCCW6CmV78uPIdPPDP bVnkqIQnlIveiaUNRfM+YeJJteD7ipJv781ZDI8gJUfAAdZ1/u3Sp8IA+CYJdgvMw+AY Xg3Utq3DgD5YshuEblBDqBhDqYlfgrlscJoJurHaOyRqQZYw3XZDDbVZtvChO4o61R/v xyIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=gDzGvDYK; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id i191si3827042pge.449.2022.02.09.11.04.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 11:04:13 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=gDzGvDYK; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5AEA2C050CC3; Wed, 9 Feb 2022 11:03:54 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231628AbiBIRyn (ORCPT + 99 others); Wed, 9 Feb 2022 12:54:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238497AbiBIRyk (ORCPT ); Wed, 9 Feb 2022 12:54:40 -0500 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A581DC05CB82 for ; Wed, 9 Feb 2022 09:54:43 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id w20so2844523plq.12 for ; Wed, 09 Feb 2022 09:54:43 -0800 (PST) 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:content-transfer-encoding:in-reply-to; bh=bn+NqQc+WkBL0eCTGvSDZFvqDNmAbZwHfh1WyoVIqEU=; b=gDzGvDYK+kanW1ZjdlzJIIEDIOwcDawCy2/WkAvLy+okpF1wNXDa6i2bZo/mYN0yKl M5ofOfdjO8Zlz/FGkjY8tI9264lB59SUqwDecmo037jiNWuD7yV3+HyGvNqwV+YUv1CQ IEjipzEqzwTiYLOSJzKFRJrGEfAMC/H3Pg77gMNkdPN9y4qlO5U5nOU/w8vY13caF7WY v+VVu0DHZjZCxM9zhvhqhxB7jiU8Z7/e9TwkESuCrdgQGH/vkvA7Kv1bc+dWKYTuctmc RV8Ebzs/wibJzv/LKWZwTjEnWPi1DuTxW3OuAT7VLQ1toSc+6gROC0oD/hjzfjjSFKeh BD9w== 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:content-transfer-encoding :in-reply-to; bh=bn+NqQc+WkBL0eCTGvSDZFvqDNmAbZwHfh1WyoVIqEU=; b=mAbdamYfxKdWX9ePnvj0DM7c4Pns/ldl/la4zelP8wrh+oT1SLLYXxiLVrdNYPQIhp V7wsB4s2vnXlIi5MaD03Kgyl9c7+HcdwUsf5y+NZmLoFcKxKjs3KKx4/BK+FAXx+m01e Ul1aGLnUEs+ba//og9vHQq9HFEOu2nyR3zz0S5GeMGFPQ56JfolMgzQtbkS5kG2WzEdr RN/Z9TgM7mjXx5+DhE2VfpYkCqxtPuS4mTw3oH182mJbL8IycoxRA4nOYqEC85/v4zA0 jw3fzOcOfBxhnscMCvlm1gm/gdKYIEMXjamOKznwhKZv60yx7Rsfs3VlpUidCHpDqTq8 PflA== X-Gm-Message-State: AOAM531wTYaRAW3Nucs7s8UUfUxt24w7RbApPpxzI+fWLH/Rp9d0ddLH 6YMMAGJyy/QQHmx5fc2kaAKcZQ== X-Received: by 2002:a17:90b:1e50:: with SMTP id pi16mr4732745pjb.16.1644429282853; Wed, 09 Feb 2022 09:54:42 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id h6sm20257216pfc.35.2022.02.09.09.54.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 09:54:42 -0800 (PST) Date: Wed, 9 Feb 2022 17:54:38 +0000 From: Sean Christopherson To: Suravee Suthikulpanit Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, x86@kernel.org, mlevitsk@redhat.com, pbonzini@redhat.com, joro@8bytes.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, peterz@infradead.org, hpa@zytor.com, jon.grimm@amd.com, wei.huang2@amd.com, terry.bowman@amd.com Subject: Re: [PATCH v5] KVM: SVM: Allow AVIC support on system w/ physical APIC ID > 255 Message-ID: References: <20220209152038.12303-1-suravee.suthikulpanit@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220209152038.12303-1-suravee.suthikulpanit@amd.com> X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 09, 2022, Suravee Suthikulpanit wrote: > AVIC physical APIC ID table entry contains host physical > APIC ID field, which is used by the hardware to keep track of where > each vCPU is running. Originally, this field is 8-bit when AVIC was > introduced. > > The AMD64 Architecture Programmer’s Manual Volume 2 revision 3.38 > specify the physical APIC ID table entry bit [11:8] as reserved > for older generation of AVIC hardware. I'd prefer to explicitly call out that older versions of the APM were buggy, it's easy to overlook the importance of the "revision 3.38" blurb. > For newer hardware, this field is used to specify host physical APIC ID > larger than 255. For all intents and purposed the field was _architecturally_ always 12 bits, the APM just did a poor job of documenting that the number of bits that are actually consumed by the CPU is model specific behavior. > Unfortunately, there is no CPUID bit to help determine if AVIC hardware > can support 12-bit host physical APIC ID. For older system, since > the reserved bits [11:8] is documented as should be zero, it should be safe Please don't hedge, "it should be safe" implies we aren't confident about writing zeroes, but KVM already writes zeroes to the reserved bits. The changelog could instead call out that KVM trusts hardware to (a) not generate bogus x2APIC IDs and (b) to always support at least 8 bits. > to increase the host physical ID mask to 12 bits and clear the field > when programing new physical APIC ID. E.g. Expand KVM's mask for the AVIC host physical ID to the full 12 bits defined by the architecture. The number of bits consumed by hardware is model specific, e.g. early CPUs ignored bits 11:8, but there is no way for KVM to enumerate the "true" size. So, KVM must allow using all bits, else it risks rejecting completely legal x2APIC IDs on newer CPUs. This means KVM relies on hardware to not assign x2APIC IDs that exceed the "true" width of the field, but presmuably hardware is smart enough to tie the width to the max x2APIC ID. KVM also relies on hardware to support at least 8 bits, as the legacy xAPIC ID is writable by software. But, those assumptions are unavoidable due to the lack of any way to enumerate the "true" width. Note, older versions of the APM state that bits 11:8 are reserved for legacy xAPIC, but consumed for x2APIC. Revision 3.38 corrected this to state that bits 11:8 are "should be zero" on older hardware. > Suggested-by: Sean Christopherson > Cc: Maxim Levitsky Cc: stable@vger.kernel.org Fixes: 44a95dae1d22 ("KVM: x86: Detect and Initialize AVIC support") > Signed-off-by: Suravee Suthikulpanit > --- > arch/x86/kvm/svm/avic.c | 8 ++------ > arch/x86/kvm/svm/svm.h | 2 +- > 2 files changed, 3 insertions(+), 7 deletions(-) > > diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c > index 90364d02f22a..54ad98731181 100644 > --- a/arch/x86/kvm/svm/avic.c > +++ b/arch/x86/kvm/svm/avic.c > @@ -19,6 +19,7 @@ > #include > #include > > +#include Unnecessary new include. With the above addressed, Reviewed-by: Sean Christopherson