qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [PATCH v9] qapi: introduce 'query-kvm-cpuid' action
Date: Mon, 21 Jun 2021 08:19:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Eduardo Habkost <ehabkost@redhat.com> writes:

> 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?

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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]