Eduardo Habkost <ehabkost@xxxxxxxxxx> writes: > 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? I can't see what's specific to KVM in the interface (it's implemented only for KVM, but that's just a restriction). The doc comment looks like the command returns whatever the guest's cpuid instruction will write to registers. Can you help me understand the interface's KVM dependence?
