All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>
Cc: qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Eric Blake <eblake@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	kvm@vger.kernel.org, Denis Lunev <den@openvz.org>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Subject: Re: [PATCH v9] qapi: introduce 'query-kvm-cpuid' action
Date: Thu, 17 Jun 2021 13:09:08 +0200	[thread overview]
Message-ID: <87a6no3fzf.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20210617074919.GA998232@dhcp-172-16-24-191.sw.ru> (Valeriy Vdovin's message of "Thu, 17 Jun 2021 10:49:19 +0300")

Valeriy Vdovin <valeriy.vdovin@virtuozzo.com> writes:

> On Thu, Jun 17, 2021 at 07:22:36AM +0200, Markus Armbruster wrote:
>> Valeriy Vdovin <valeriy.vdovin@virtuozzo.com> writes:
>> 
>> > Introducing new qapi method 'query-kvm-cpuid'. This method can be used to
>> 
>> It's actually a QMP command.  There are no "qapi methods".
>> 
>> > get virtualized cpu model info generated by QEMU during VM initialization in
>> > the form of cpuid representation.
>> >
>> > Diving into more details about virtual cpu generation: QEMU first parses '-cpu'
>> 
>> virtual CPU
>> 
>> > command line option. From there it takes the name of the model as the basis for
>> > feature set of the new virtual cpu. After that it uses trailing '-cpu' options,
>> > that state if additional cpu features should be present on the virtual cpu or
>> > excluded from it (tokens '+'/'-' or '=on'/'=off').
>> > After that QEMU checks if the host's cpu can actually support the derived
>> > feature set and applies host limitations to it.
>> > After this initialization procedure, virtual cpu has it's model and
>> > vendor names, and a working feature set and is ready for identification
>> > instructions such as CPUID.
>> >
>> > Currently full output for this method is only supported for x86 cpus.
>> 
>> Not sure about "currently": the interface looks quite x86-specific to me.
>> 
> Yes, at some point I was thinking this interface could become generic,
> but does not seem possible, so I'll remove this note.
>
>> The commit message doesn't mention KVM except in the command name.  The
>> schema provides the command only if defined(CONFIG_KVM).
>> 
>> Can you explain why you need the restriction to CONFIG_KVM?
>> 
> This CONFIG_KVM is used as a solution to a broken build if --disable-kvm
> flag is set. I was choosing between this and writing empty implementation into
> kvm-stub.c

If the command only makes sense for KVM, then it's named correctly, but
the commit message lacks a (brief!) explanation why it only makes for
KVM.

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.

Pick one :)

[...]


WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, Denis Lunev <den@openvz.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH v9] qapi: introduce 'query-kvm-cpuid' action
Date: Thu, 17 Jun 2021 13:09:08 +0200	[thread overview]
Message-ID: <87a6no3fzf.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20210617074919.GA998232@dhcp-172-16-24-191.sw.ru> (Valeriy Vdovin's message of "Thu, 17 Jun 2021 10:49:19 +0300")

Valeriy Vdovin <valeriy.vdovin@virtuozzo.com> writes:

> On Thu, Jun 17, 2021 at 07:22:36AM +0200, Markus Armbruster wrote:
>> Valeriy Vdovin <valeriy.vdovin@virtuozzo.com> writes:
>> 
>> > Introducing new qapi method 'query-kvm-cpuid'. This method can be used to
>> 
>> It's actually a QMP command.  There are no "qapi methods".
>> 
>> > get virtualized cpu model info generated by QEMU during VM initialization in
>> > the form of cpuid representation.
>> >
>> > Diving into more details about virtual cpu generation: QEMU first parses '-cpu'
>> 
>> virtual CPU
>> 
>> > command line option. From there it takes the name of the model as the basis for
>> > feature set of the new virtual cpu. After that it uses trailing '-cpu' options,
>> > that state if additional cpu features should be present on the virtual cpu or
>> > excluded from it (tokens '+'/'-' or '=on'/'=off').
>> > After that QEMU checks if the host's cpu can actually support the derived
>> > feature set and applies host limitations to it.
>> > After this initialization procedure, virtual cpu has it's model and
>> > vendor names, and a working feature set and is ready for identification
>> > instructions such as CPUID.
>> >
>> > Currently full output for this method is only supported for x86 cpus.
>> 
>> Not sure about "currently": the interface looks quite x86-specific to me.
>> 
> Yes, at some point I was thinking this interface could become generic,
> but does not seem possible, so I'll remove this note.
>
>> The commit message doesn't mention KVM except in the command name.  The
>> schema provides the command only if defined(CONFIG_KVM).
>> 
>> Can you explain why you need the restriction to CONFIG_KVM?
>> 
> This CONFIG_KVM is used as a solution to a broken build if --disable-kvm
> flag is set. I was choosing between this and writing empty implementation into
> kvm-stub.c

If the command only makes sense for KVM, then it's named correctly, but
the commit message lacks a (brief!) explanation why it only makes for
KVM.

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.

Pick one :)

[...]



  reply	other threads:[~2021-06-17 11:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03  9:07 [PATCH v9] qapi: introduce 'query-kvm-cpuid' action Valeriy Vdovin
2021-06-03 12:29 ` Vladimir Sementsov-Ogievskiy
2021-06-17  5:22 ` Markus Armbruster
2021-06-17  5:22   ` Markus Armbruster
2021-06-17  7:49   ` Valeriy Vdovin
2021-06-17 11:09     ` Markus Armbruster [this message]
2021-06-17 11:09       ` Markus Armbruster
2021-06-17 11:56       ` Claudio Fontana
2021-06-17 11:56         ` Claudio Fontana
2021-06-17 14:14         ` Markus Armbruster
2021-06-17 14:14           ` Markus Armbruster
2021-06-17 15:39           ` Valeriy Vdovin
2021-06-17 15:53             ` Claudio Fontana
2021-06-17 15:53               ` Claudio Fontana
2021-06-17 16:51               ` Eduardo Habkost
2021-06-17 16:51                 ` Eduardo Habkost
2021-06-18  5:52                 ` Markus Armbruster
2021-06-18  5:52                   ` Markus Armbruster
2021-06-18 20:40                   ` Eduardo Habkost
2021-06-18 20:40                     ` Eduardo Habkost
2021-06-21  6:19                     ` Markus Armbruster
2021-06-21  6:19                       ` Markus Armbruster
2021-06-21  8:07                     ` Claudio Fontana
2021-06-21  8:07                       ` Claudio Fontana
2021-06-21 14:23                       ` Eduardo Habkost
2021-06-21 14:23                         ` Eduardo Habkost
2021-06-21 15:50                         ` Markus Armbruster
2021-06-21 15:50                           ` Markus Armbruster
2021-06-21 16:09                           ` Valeriy Vdovin
2021-06-30  7:28                             ` Valeriy Vdovin
2021-06-17 11:58     ` Claudio Fontana
2021-06-17 11:58       ` Claudio Fontana
2021-06-17 13:47       ` Valeriy Vdovin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a6no3fzf.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thuth@redhat.com \
    --cc=valeriy.vdovin@virtuozzo.com \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.