All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Gurtovoy <mgurtovoy@nvidia.com>
To: Cornelia Huck <cohuck@redhat.com>,
	virtio-dev@lists.oasis-open.org,
	virtio-comment@lists.oasis-open.org, Oren Duer <oren@nvidia.com>,
	Parav Pandit <parav@nvidia.com>,
	Shahaf Shuler <shahafs@nvidia.com>
Subject: Re: [PATCH] Reserve more feature bits for device type usage
Date: Wed, 2 Feb 2022 17:14:51 +0200	[thread overview]
Message-ID: <34a503f0-2e5f-9d22-e298-8dbcd90f9952@nvidia.com> (raw)
In-Reply-To: <87zgn9wjb4.fsf@redhat.com>


On 2/2/2022 2:21 PM, Cornelia Huck wrote:
> On Wed, Feb 02 2022, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:
>
>> On 2/2/2022 1:52 PM, Cornelia Huck wrote:
>>> On Wed, Feb 02 2022, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:
>>>
>>>> On 1/14/2022 1:12 PM, Cornelia Huck wrote:
>>>>> Feature bits 41 and above are noted as being reserved for future
>>>>> extensions. However, the net device has been using bits in that space
>>>>> for some time now, as it already used up the device type specific
>>>>> range up to 23.
>>>>>
>>>>> To avoid problems in the future, let's designate bits 50 to 127 to
>>>>> device type specific usage (which accommodates current usage by the
>>>>> net driver, and gives breathing room for future type specific bits),
>>>>> and declare bits 41 to 49 and bits 128 and above to be reserved for
>>>>> future extensions (which gives us some time before bit numbers move
>>>>> beyond 63, which would need some changes in existing device and driver
>>>>> implementations.)
>>>>>
>>>>> Reported-by: Max Gurtovoy <mgurtovoy@nvidia.com>
>>>>> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/131
>>>>> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
>>>>> ---
>>>>>     content.tex | 4 ++--
>>>>>     1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/content.tex b/content.tex
>>>>> index 32de6685c50b..c6f116c7aa39 100644
>>>>> --- a/content.tex
>>>>> +++ b/content.tex
>>>>> @@ -97,12 +97,12 @@ \section{Feature Bits}\label{sec:Basic Facilities of a Virtio Device / Feature B
>>>>>     Feature bits are allocated as follows:
>>>>>     
>>>>>     \begin{description}
>>>>> -\item[0 to 23] Feature bits for the specific device type
>>>>> +\item[0 to 23, and 50 to 127] Feature bits for the specific device type
>>>>>     
>>>>>     \item[24 to 40] Feature bits reserved for extensions to the queue and
>>>>>       feature negotiation mechanisms
>>>>>     
>>>>> -\item[41 and above] Feature bits reserved for future extensions.
>>>>> +\item[41 to 49, and 128 and above] Feature bits reserved for future extensions.
>>>>>     \end{description}
>>>>>     
>>>>>     \begin{note}
>>>> Cornelia,
>>>>
>>>> I've noticed that Legacy net device has VIRTIO_NET_F_GUEST_RSC4 (41) and
>>>> VIRTIO_NET_F_GUEST_RSC6 (42).
>>>>
>>>> Do we need to reserved them too or keep the fix as-is ?
>>> Eww. I think those bits shouldn't have been hiding in the "legacy"
>>> section, as their higher number indicates that they are not for a legacy
>>> device in the spec sense.
>>>
>>> They have been introduced in
>>> https://github.com/oasis-tcs/virtio-spec/issues/21 in 2018, I'm
>>> wondering how old those Windows drivers referred to in there are. IOW,
>>> would a new feature bit 41/42 break things for currently used Windows
>>> drivers if it showed up on a virtio-net device? If we still care about
>>> those drivers, we should reserve bits 41 and 42 as do-not-use, I guess.
>> I've not idea about the windows drivers.
>>
>> But the bit 41 is currently the bit I use to negotiate the AQ in the
>> last patchset so we need to decide how to progress.
> For your purpose, it would probably be best to simply go with 43 in your
> next update.

it won't align with the Feature bits section so I'll keep it 41 for v3 
and hope it will be resolved by v4...

>
> We have to come to a conclusion before we merge any new feature using a
> bit in that range anyway... and I really would like to have that cleared
> up before we do our draft :/
>


      reply	other threads:[~2022-02-02 15:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14 11:12 [PATCH] Reserve more feature bits for device type usage Cornelia Huck
2022-01-16  9:41 ` Max Gurtovoy
2022-02-02 10:52 ` Max Gurtovoy
2022-02-02 11:52   ` [virtio-dev] " Cornelia Huck
2022-02-02 12:06     ` Max Gurtovoy
2022-02-02 12:21       ` [virtio-comment] " Cornelia Huck
2022-02-02 15:14         ` Max Gurtovoy [this message]

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=34a503f0-2e5f-9d22-e298-8dbcd90f9952@nvidia.com \
    --to=mgurtovoy@nvidia.com \
    --cc=cohuck@redhat.com \
    --cc=oren@nvidia.com \
    --cc=parav@nvidia.com \
    --cc=shahafs@nvidia.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@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 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.