From: Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
Claudio Fontana <cfontana@suse.de>,
Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, Denis Lunev <den@openvz.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH v9] qapi: introduce 'query-kvm-cpuid' action
Date: Wed, 30 Jun 2021 10:28:08 +0300 [thread overview]
Message-ID: <20210630072808.GA67573@dhcp-172-16-24-191.sw.ru> (raw)
In-Reply-To: <20210621160951.GA686102@dhcp-172-16-24-191.sw.ru>
On Mon, Jun 21, 2021 at 07:09:51PM +0300, Valeriy Vdovin wrote:
> On Mon, Jun 21, 2021 at 05:50:55PM +0200, Markus Armbruster wrote:
> > Eduardo Habkost <ehabkost@redhat.com> writes:
> >
> > > On Mon, Jun 21, 2021 at 10:07:44AM +0200, Claudio Fontana wrote:
> > >> On 6/18/21 10:40 PM, Eduardo Habkost wrote:
> > >> > On Fri, Jun 18, 2021 at 07:52:47AM +0200, Markus Armbruster wrote:
> > >> >> Eduardo Habkost <ehabkost@redhat.com> writes:
> > >> >>
> > >> >>> On Thu, Jun 17, 2021 at 05:53:11PM +0200, Claudio Fontana wrote:
> > >> >>>> On 6/17/21 5:39 PM, Valeriy Vdovin wrote:
> > >> >>>>> On Thu, Jun 17, 2021 at 04:14:17PM +0200, Markus Armbruster wrote:
> > >> >>>>>> Claudio Fontana <cfontana@suse.de> writes:
> > >> >>>>>>
> > >> >>>>>>> On 6/17/21 1:09 PM, Markus Armbruster wrote:
> > >> >>
> > >> >> [...]
> > >> >>
> > >> >>>>>>>> If it just isn't implemented for anything but KVM, then putting "kvm"
> > >> >>>>>>>> into the command name is a bad idea. Also, the commit message should
> > >> >>>>>>>> briefly note the restriction to KVM.
> > >> >>>>>>
> > >> >>>>>> Perhaps this one is closer to reality.
> > >> >>>>>>
> > >> >>>>> I agree.
> > >> >>>>> What command name do you suggest?
> > >> >>>>
> > >> >>>> query-exposed-cpuid?
> > >> >>>
> > >> >>> Pasting the reply I sent at [1]:
> > >> >>>
> > >> >>> I don't really mind how the command is called, but I would prefer
> > >> >>> to add a more complex abstraction only if maintainers of other
> > >> >>> accelerators are interested and volunteer to provide similar
> > >> >>> functionality. I don't want to introduce complexity for use
> > >> >>> cases that may not even exist.
> > >> >>>
> > >> >>> I'm expecting this to be just a debugging mechanism, not a stable
> > >> >>> API to be maintained and supported for decades. (Maybe a "x-"
> > >> >>> prefix should be added to indicate that?)
> > >> >>>
> > >> >>> [1] https://lore.kernel.org/qemu-devel/20210602204604.crsxvqixkkll4ef4@habkost.net
> > >> >>
> > >> >> x-query-x86_64-cpuid?
> > >> >>
> > >> >
> > >> > Unless somebody wants to spend time designing a generic
> > >> > abstraction around this (and justify the extra complexity), this
> > >> > is a KVM-specific command. Is there a reason to avoid "kvm" in
> > >> > the command name?
> > >> >
> > >>
> > >> If the point of all of this is "please get me the cpuid, as seen by the guest", then I fail to see how this should be kvm-only.
> > >> We can still return "not implemented" of some kind for HVF, TCG etc.
> > >>
> > >> But maybe I misread the use case?
> > >
> > > A generic interface would require additional glue to connect the
> > > generic code to the accel-specific implementation. I'm trying to
> > > avoid wasting everybody's time with the extra complexity unless
> > > necessary.
> >
> > If I read the patch correctly, the *interface* is specific to x86_64,
> > but not to any accelerator. It's *implemented* only for KVM, though.
> > Is that correct?
> >
> Yes, it's a x86 specific instruction, and KVM is a bit of implementation
> detail right now. It could actually have stubs in other accels instead
> of CONFIG_KVM.
>
> > > But if you all believe the extra complexity is worth it, I won't
> > > object.
> >
> > I'm not arguing for a complete implementation now.
> >
> > I think the command name is a matter of taste.
> >
> > The command exists only if defined(TARGET_I386). Putting -x86_64- or
> > similar in the name isn't strictly required, but why not. Maybe just
> > -x86-.
> >
> > Putting -kvm- in the name signals (1) the command works only with KVM,
> > and (2) we don't intend to make it work with other accelerators. If we
> > later decide to make it work with other accelerators, we get to rename
> > the command.
> >
> > Not putting -kvm- in the name doesn't commit us to anything.
> >
> > Either way, the command exists and fails when defined(CONFIG_KVM) and
> > accel!=kvm.
> >
> > Aside: I think having the command depend on defined(CONFIG_KVM)
> > accomplishes nothing but enlarging the test matrix:
> >
> > defined(CONFIG_KVM) and accel=kvm command exists and works
> > defined(CONFIG_KVM) and accel!=kvm command exists and fails
> > !defined(CONFIG_KVM) command does not exist
> >
> > Simpler:
> >
> > accel=kvm command exists and works
> > accel!=kvm command exists and fails
> >
> Well, it accomplishes not having stub implementations all over the place.
> But looks like having the right error message in stubs really seems more
> appropriate.
>
> Your reasoning is pretty clear and in the light of it I now fill that
> platform in the name is better that one of the possible accel implementations
> in the name.
>
> So should the command name be renamed from 'query-kvm-cpuid' to
> 'query-x86-cpuid'?
>
> And considering CONFIG_KVM, I guess it would be better to drop this ifdef and
> instead put stub functions in several places? If yes, please let me know
> the exact list of places that should have that stub, as well as the right way
> to state the "unimplemented" error for these stubs, (sorry, this last
> one is just to shorten some of the iterations)
>
> Thanks.
Hello.
I'm waiting some kind of response/confirmation on this message, so I could continue.
next prev parent reply other threads:[~2021-06-30 7:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 9:07 [PATCH v9] qapi: introduce 'query-kvm-cpuid' action Valeriy Vdovin
2021-06-03 12:29 ` Vladimir Sementsov-Ogievskiy
2021-06-17 5:22 ` Markus Armbruster
2021-06-17 7:49 ` Valeriy Vdovin
2021-06-17 11:09 ` Markus Armbruster
2021-06-17 11:56 ` Claudio Fontana
2021-06-17 14:14 ` Markus Armbruster
2021-06-17 15:39 ` Valeriy Vdovin
2021-06-17 15:53 ` Claudio Fontana
2021-06-17 16:51 ` Eduardo Habkost
2021-06-18 5:52 ` Markus Armbruster
2021-06-18 20:40 ` Eduardo Habkost
2021-06-21 6:19 ` Markus Armbruster
2021-06-21 8:07 ` Claudio Fontana
2021-06-21 14:23 ` Eduardo Habkost
2021-06-21 15:50 ` Markus Armbruster
2021-06-21 16:09 ` Valeriy Vdovin
2021-06-30 7:28 ` Valeriy Vdovin [this message]
2021-06-17 11:58 ` Claudio Fontana
2021-06-17 13:47 ` Valeriy Vdovin
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=20210630072808.GA67573@dhcp-172-16-24-191.sw.ru \
--to=valeriy.vdovin@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=cfontana@suse.de \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lvivier@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=vsementsov@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).