Re: [libvirt][PATCH RESEND v12 0/6] Support query and use SGX
On Thu, Jun 02, 2022 at 22:49:15 +0000, Yang, Lin A wrote:
On 6/2/22, 11:28 AM, "Yang, Lin A"
<lin.a.yang(a)intel.com> wrote:
> On 6/1/22, 11:37 PM, "Michal Prívozník" <mprivozn(a)redhat.com> wrote:
[...]
> > So maybe in the end libvirt CAN know the difference without
having to do
> > any version check. We have a "dialect" of XPATH that we use to
traverse
> > the QMP schema: look at the comment above virQEMUQAPISchemaPathGet().
>
> This is awesome! Thank you so much for this very informative explanation.
> QEMU 7.0.0 provides more NUMA info in SGX part, so if we see "sections"
in
> QAPI schema, we can assume .node attribute is required.
>
> Let me try this solution at first. We can support both QEMU 6.2.0 and 7.0.0 in
> V13 patches if it is doable.
Sorry for multiple emails here.
Since these patches here have been review several times, and support 7.0.0 will bring
some new commits. Each update to new commit will require git rebase and resolve
conflict for old commits. Is it possible that we add the feature to compare QAPI schema
and detect .node, but only work with 6.2.0 in this patch and return error message for
7.0.0. After finishing this thread, we can start a new thread to support NUMA for qemu
7.0.0. Any preference?
Usually we prefer if everything is done in one series, but obviously
that is not always possible.
In case you want to commit partially-incomplete patches you need to
ensure that they behave sanely for anyone attempting to use it.
This means mostly that if e.g. your code would work with qemu-6.2 and
would then break with qemu-7.0 it _must_ be kept disabled.
I didn't go through the conversation here, but from the above it seems
that you are discussing that there are two distinct ways how to detect
the presence of the feature in qemu between qemu-6.2 and qemu-7.0.
If that is true then I'd simply say it's strongly preferrable to just
drop the code for qemu-6.2 and just do the necessary steps to make it
work with qemu-7.0. Adding another bit of code just to make it work with
one extra version doesn't seem to be worth it unless you have a very
good justification, because it's more code that we'll have to maintain
in the end.