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? Thanks, C
