All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Claudio Fontana <cfontana@suse.de>
Cc: Markus Armbruster <armbru@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Denis Lunev <den@openvz.org>, Eric Blake <eblake@redhat.com>,
	Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>
Subject: Re: [PATCH v9] qapi: introduce 'query-kvm-cpuid' action
Date: Mon, 21 Jun 2021 10:23:29 -0400	[thread overview]
Message-ID: <20210621142329.atlhrovqkblbjwgh@habkost.net> (raw)
In-Reply-To: <6f644bbb-52ff-4d79-36bb-208c6b6c4eef@suse.de>

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


WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com>
To: Claudio Fontana <cfontana@suse.de>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	kvm@vger.kernel.org, Marcelo Tosatti <mtosatti@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org,
	Valeriy Vdovin <valeriy.vdovin@virtuozzo.com>,
	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: Mon, 21 Jun 2021 10:23:29 -0400	[thread overview]
Message-ID: <20210621142329.atlhrovqkblbjwgh@habkost.net> (raw)
In-Reply-To: <6f644bbb-52ff-4d79-36bb-208c6b6c4eef@suse.de>

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



  reply	other threads:[~2021-06-21 14:23 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
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 [this message]
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=20210621142329.atlhrovqkblbjwgh@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=cfontana@suse.de \
    --cc=den@openvz.org \
    --cc=eblake@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.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.