Discussion of the VIRTIO specification
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Max Gurtovoy <mgurtovoy@nvidia.com>,
	Cornelia Huck <cohuck@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-comment@lists.oasis-open.org, stefanha@redhat.com,
	oren@nvidia.com, parav@nvidia.com, shahafs@nvidia.com,
	eperezma@redhat.com, aadam@redhat.com, bodong@nvidia.com,
	amikheev@nvidia.com, Laurent Vivier <lvivier@redhat.com>
Subject: Re: [RFC PATCH v2 1/2] Add virtio Admin Virtqueue specification
Date: Tue, 3 Aug 2021 11:39:25 +0800	[thread overview]
Message-ID: <1f4fd34c-bd6a-bfbf-a7df-cba697dc71c6@redhat.com> (raw)
In-Reply-To: <abbc3417-5636-4e06-d47b-123473f8bc4a@nvidia.com>


在 2021/8/2 下午11:27, Max Gurtovoy 写道:
>
> On 8/2/2021 5:51 PM, Cornelia Huck wrote:
>> On Mon, Aug 02 2021, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:
>>
>>> On 8/2/2021 5:17 AM, Jason Wang wrote:
>>>> 在 2021/8/1 上午6:53, Max Gurtovoy 写道:
>>>>> On 8/1/2021 1:26 AM, Michael S. Tsirkin wrote:
>>>>>> On Sat, Jul 31, 2021 at 02:34:25PM +0300, Max Gurtovoy wrote:
>>>>>>> On 7/30/2021 10:05 AM, Cornelia Huck wrote:
>>>>>>>> On Thu, Jul 29 2021, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:
>>>>>>>>
>>>>>>>>> On 7/28/2021 3:48 PM, Michael S. Tsirkin wrote:
>>>>>>>>>> On Mon, Jul 26, 2021 at 07:52:53PM +0300, Max Gurtovoy wrote:
>>>>>>>>>>> +\subsubsection{Vendor specific command set}\label{sec:Basic
>>>>>>>>>>> Facilities of a Virtio Device / Admin Virtqueues / Admin
>>>>>>>>>>> command set / Vendor specific command set}
>>>>>>>>>>> +
>>>>>>>>>>> +The Vendor specific command set is a group of classes and
>>>>>>>>>>> commands
>>>>>>>>>>> +within each of these classes which are vendor specific. 
>>>>>>>>>>> Refer to
>>>>>>>>>>> +each vendor specification for more information on the 
>>>>>>>>>>> supported
>>>>>>>>>>> +commands.
>>>>>>>>>> Here's another example.
>>>>>>>>>> It's important that there is a way to make a device completely
>>>>>>>>>> generic without vendor specific expensions.
>>>>>>>>>> Would be hard to do here.
>>>>>>>>>>
>>>>>>>>>> That's a generic comment.
>>>>>>>>>>
>>>>>>>>>> but specifically I am very reluctant to add vendor specific
>>>>>>>>>> stuff like
>>>>>>>>>> this directly in the spec. We already have
>>>>>>>>>> VIRTIO_PCI_CAP_VENDOR_CFG
>>>>>>>>>> and if that is not sufficient I would like to know why
>>>>>>>>>> before we add more vendor specific stuff.
>>>>>>>>> We are adding an option to add vendor specific commands. We're 
>>>>>>>>> not
>>>>>>>>> adding it to the spec since each vendor will have its own 
>>>>>>>>> manual for
>>>>>>>>> that.
>>>>>>>> IMHO, that way madness lies. I want to be able to look at the spec
>>>>>>>> and
>>>>>>>> be able to implement a compliant device or a compliant driver. 
>>>>>>>> If a
>>>>>>>> vendor has some special feature they want to support, put it in 
>>>>>>>> the
>>>>>>>> spec, so that it is possible to actually implement it.
>>>>>>> You can implement a compliant device and a compliant. why do you
>>>>>>> think you
>>>>>>> can't ?
>> If I want to implement a device/driver, I need a standard to refer
>> to. How can something vendor-specific be standard? If it is useful, add
>> it to the virtio spec.
>
> again, Linux driver will be generic.
>
> It will include a char dev to user space virtio-cli that will enable 
> sending admin commands to do administration.
>
> Nobody asked to add vendor specific code to the driver.


It's not about the general driver but about the general device. We want 
to present a general standard device which means we can migrate virtio 
devices among different vendors.

If each vendor choose to implement their own vendor specific features 
via vendor specific commands that are not ruled by the spec, there will 
be little value of the spec.


>
> The spec allows vendor specific stuff today that are not usable and 
> I'm trying to create a usable API without adding one line of vendor 
> code to driver.
>
> You just need to open a window for few commands like others do and 
> like you already did in the spec.
>
> NVIDIA HW internals are different from VENDOR_A and VENDOR_B.
>
> I want to debug my HW or enable some accelerations in it.


A big question is that, on what layer do you want to provide those 
functions?

1) virtio level
2) vendor level

For 1), it needs to be done in the spec instead of introducing backdoor 
for vendor specific command

For 2), virtio keeps simple as is, functionality is provided in a vendor 
specific device interface. In this case, you can't use virtio-pci 
directly, then you need present virtio on the upper layer (with some 
software meditation)


>
> This is the way to do it.


Again, for debug or acceleration, if you want to do it at the virtio 
level, you need generalize those features and define them in the spec.

Maybe we can start the work on generalizing the debug facility first. 
(adding Laurent who is working on this).

Tahnks


  parent reply	other threads:[~2021-08-03  3:39 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26 16:52 [RFC PATCH v2 1/2] Add virtio Admin Virtqueue specification Max Gurtovoy
2021-07-26 16:52 ` [RFC PATCH v2 2/2] virtio-blk: add support for VIRTIO_F_ADMIN_VQ Max Gurtovoy
2021-07-27 12:24   ` Stefan Hajnoczi
2021-07-27 16:08     ` [virtio-comment] " Max Gurtovoy
2021-07-28  8:25       ` Stefan Hajnoczi
2021-07-27 10:27 ` [RFC PATCH v2 1/2] Add virtio Admin Virtqueue specification Stefan Hajnoczi
2021-07-27 14:28   ` [virtio-comment] " Cornelia Huck
2021-07-27 15:29     ` Max Gurtovoy
2021-07-28  8:52       ` Stefan Hajnoczi
2021-07-28 10:59         ` Max Gurtovoy
2021-07-28 13:42           ` Stefan Hajnoczi
2021-07-28 14:20             ` Max Gurtovoy
2021-07-29  8:48               ` Stefan Hajnoczi
2021-08-01 10:46                 ` [virtio-comment] " Max Gurtovoy
2021-08-02 12:58                   ` Stefan Hajnoczi
2021-07-28 12:53       ` Michael S. Tsirkin
2021-07-30  6:45         ` [virtio-comment] " Cornelia Huck
2021-07-28 12:48 ` Michael S. Tsirkin
2021-07-29 14:51   ` Max Gurtovoy
2021-07-30  7:05     ` [virtio-comment] " Cornelia Huck
2021-07-31 11:34       ` Max Gurtovoy
2021-07-31 22:26         ` Michael S. Tsirkin
2021-07-31 22:53           ` Max Gurtovoy
2021-08-01  8:16             ` Michael S. Tsirkin
2021-08-01  8:38               ` Max Gurtovoy
2021-08-02  2:17             ` Jason Wang
2021-08-02  2:19               ` Jason Wang
2021-08-02  9:54               ` Max Gurtovoy
2021-08-02 14:51                 ` [virtio-comment] " Cornelia Huck
2021-08-02 15:27                   ` Max Gurtovoy
2021-08-02 17:28                     ` Michael S. Tsirkin
2021-08-03  3:39                     ` Jason Wang [this message]
2021-08-03  8:32                       ` Max Gurtovoy
2021-08-03  9:01                         ` Jason Wang
2021-08-03  9:21                           ` Max Gurtovoy
2021-08-03 10:04                             ` [virtio-comment] " Jason Wang
2021-07-30  7:36     ` Michael S. Tsirkin
2021-07-31 11:53       ` Max Gurtovoy
2021-07-31 22:17         ` Michael S. Tsirkin
2021-07-31 23:46           ` Max Gurtovoy
2021-08-02 13:22             ` Stefan Hajnoczi
2021-08-02 14:34               ` [virtio-comment] " Cornelia Huck
2021-08-02 14:58                 ` Max Gurtovoy
2021-08-02 16:39                   ` Stefan Hajnoczi
2021-08-02 15:21             ` [virtio-comment] " Cornelia Huck
2021-08-02 16:03               ` Max Gurtovoy
2021-08-02 17:05                 ` Michael S. Tsirkin
2021-08-03  6:28                   ` [virtio-comment] " Cornelia Huck
2021-08-03  6:41                     ` Jason Wang
2021-08-03  6:51                       ` [virtio-comment] " Cornelia Huck
2021-08-03  7:55                         ` Max Gurtovoy
2021-08-03  8:55                           ` Cornelia Huck
2021-08-03  9:04                             ` Max Gurtovoy
2021-08-02  2:25   ` Jason Wang
2021-08-02  9:51     ` Max Gurtovoy
2021-08-02 17:07     ` Michael S. Tsirkin
2021-08-03  3:22       ` Jason Wang

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=1f4fd34c-bd6a-bfbf-a7df-cba697dc71c6@redhat.com \
    --to=jasowang@redhat.com \
    --cc=aadam@redhat.com \
    --cc=amikheev@nvidia.com \
    --cc=bodong@nvidia.com \
    --cc=cohuck@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mgurtovoy@nvidia.com \
    --cc=mst@redhat.com \
    --cc=oren@nvidia.com \
    --cc=parav@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox