Re: [PATCH v9] qapi: introduce 'query-kvm-cpuid' action

[Eduardo Habkost]

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] 
> >>> 20210602204604.crsxvqixkkll4ef4@habkost.net">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.

But if you all believe the extra complexity is worth it, I won't
object.

-- 
Eduardo