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@xxxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxx > >> > >> 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
