From: Chao Gao <chao.gao@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Naveen N Rao <naveen@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Xin Li <xin@zytor.com>, Xiaoyao Li <xiaoyao.li@intel.com>,
Binbin Wu <binbin.wu@linux.intel.com>,
Yan Zhao <yan.y.zhao@intel.com>
Subject: Re: [PATCH v3 2/6] KVM: SVM: Update "APICv in x2APIC without x2AVIC" in avic.c, not svm.c
Date: Mon, 22 Sep 2025 15:08:05 +0800 [thread overview]
Message-ID: <aND11RilfAPJ7ud6@intel.com> (raw)
In-Reply-To: <aM1mVMXptK-sko3f@google.com>
>Question then. Does anyone have a preference/opinion between explicitly passing
>in ops to vendor specific helpers, vs. making {svm,vt}_x86_ops globally visible?
>
>I don't love creating "hidden" dependencies, in quotes because in this case it's
>relatively easy to establish that the setup() helpers modify {svm,vt}_x86_ops,
>i.e. surprises should be rare.
>
>On the other hand, I do agree it's helpful to be able to see exactly where
>{svm,vt}_x86_ops are updated.
I think passing in ops to vendor-specific helpers looks a bit indirect as the
parameter should always be svm_x86_ops for AMD or vt_x86_ops for Intel.
I slightly prefer making {svm,vt}_x86_ops globally visible.
>
>And most importantly, I want to be consistent between VMX and SVM, i.e. I want
>to pick one and stick with it.
next prev parent reply other threads:[~2025-09-22 7:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-19 0:21 [PATCH v3 0/6] KVM: SVM: Enable AVIC for Zen4+ (if x2AVIC) Sean Christopherson
2025-09-19 0:21 ` [PATCH v3 1/6] KVM: SVM: Move x2AVIC MSR interception helper to avic.c Sean Christopherson
2025-09-19 9:35 ` Naveen N Rao
2025-09-19 0:21 ` [PATCH v3 2/6] KVM: SVM: Update "APICv in x2APIC without x2AVIC" in avic.c, not svm.c Sean Christopherson
2025-09-19 9:42 ` Naveen N Rao
2025-09-19 14:21 ` Sean Christopherson
2025-09-22 7:08 ` Chao Gao [this message]
2025-09-19 0:21 ` [PATCH v3 3/6] KVM: SVM: Always print "AVIC enabled" separately, even when force enabled Sean Christopherson
2025-09-19 9:52 ` Naveen N Rao
2025-09-19 0:21 ` [PATCH v3 4/6] KVM: SVM: Don't advise the user to do force_avic=y (when x2AVIC is detected) Sean Christopherson
2025-09-19 10:26 ` Naveen N Rao
2025-09-19 0:21 ` [PATCH v3 5/6] KVM: SVM: Move global "avic" variable to avic.c Sean Christopherson
2025-09-19 10:31 ` Naveen N Rao
2025-09-19 14:44 ` Sean Christopherson
2025-09-19 18:27 ` Naveen N Rao
2025-09-19 0:21 ` [PATCH v3 6/6] KVM: SVM: Enable AVIC by default for Zen4+ if x2AVIC is support Sean Christopherson
2025-09-19 10:37 ` Naveen N Rao
2025-09-19 21:56 ` Sean Christopherson
2025-09-19 10:42 ` [PATCH v3 0/6] KVM: SVM: Enable AVIC for Zen4+ (if x2AVIC) Naveen N Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aND11RilfAPJ7ud6@intel.com \
--to=chao.gao@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=naveen@kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=xiaoyao.li@intel.com \
--cc=xin@zytor.com \
--cc=yan.y.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.