From: "Alex Bennée" <alex.bennee@linaro.org>
To: Hanna Czenczek <hreitz@redhat.com>
Cc: "Yajun Wu" <yajunw@nvidia.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"virtio-fs@redhat.com" <virtio-fs@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Anton Kuchin" <antonkuchin@yandex-team.ru>,
"Parav Pandit" <parav@nvidia.com>,
"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>
Subject: Re: [Virtio-fs] (no subject)
Date: Tue, 10 Oct 2023 11:36:31 +0100 [thread overview]
Message-ID: <87lecapxi4.fsf@linaro.org> (raw)
In-Reply-To: <9a36a319-4567-f297-f14a-2025792ae93f@redhat.com>
Hanna Czenczek <hreitz@redhat.com> writes:
> On 10.10.23 06:00, Yajun Wu wrote:
>>
>> On 10/9/2023 5:13 PM, Hanna Czenczek wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> On 09.10.23 11:07, Hanna Czenczek wrote:
>>>> On 09.10.23 10:21, Hanna Czenczek wrote:
>>>>> On 07.10.23 04:22, Yajun Wu wrote:
>>>> [...]
>>>>
<snip>
> So as far as I understand, the feature is supposed to rely on
> implementation-specific behavior between specifically qemu as a
> front-end and dpdk as a back-end, nothing else. Honestly, that to me
> is a very good reason to deprecate it. That would make it clear that
> any implementation that implements it does so because it relies on
> implementation-specific behavior from other implementations.
>
> Option 2 is to fix it. It is not right to use this broadly defined
> feature with its clear protocol as given in the virtio specification
> just to set and clear a single bit (DRIVER_OK). The vhost-user
> specification points to that virtio protocol. We must adhere to the
> protocol. And note that we must not reset devices just because the VM
> is paused/resumed. (That is why I wanted to deprecate SET_STATUS, so
> that Stefan’s series would introduce RESET_DEVICE where we need it,
> and we can (for now) ignore the SET_STATUS 0 in vhost_dev_stop().)
>
> Option 3 would be to just be honest in the specification, and limit
> the scope of F_STATUS to say the only bit that matters is DRIVER_OK.
> I would say this is not really different from deprecating, though it
> wouldn’t affect your case. However, I understand Alex relies on a
> full status byte. I’m still interested to know why that is.
For an F_TRANSPORT backend (or whatever the final name ends up being) we
need the backend to have full control of the status byte because all the
handling of VirtIO is deferred to it. Therefor it has to handle all the
feature negotiation and indicate when the device needs resetting.
(side note: feature negotiation is another slippery area when QEMU gets
involved in gating which feature bits may or may not be exposed to the
backend. The only one it should ever mask is F_UNUSED which is used
(sic) to trigger the vhost protocol negotiation)
> Option 4 is of course not to do anything, and leave everything as-is,
> waiting for the next person to stir the hornet’s nest.
>
>>>> Cc-ing Alex on this mail, because to me, this seems like an important
>>>> detail when he plans on using the byte in the future. If we need a
>>>> virtio status byte, I can’t see how we could use the existing F_STATUS
>>>> for it.
What would we use instead of F_STATUS to query the Device Status field?
>>>>
>>>> Hanna
>>
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-10-10 10:45 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-04 12:58 [PATCH v4 0/8] vhost-user: Back-end state migration Hanna Czenczek
2023-10-04 12:58 ` [PATCH v4 1/8] vhost-user.rst: Deprecate [GS]ET_STATUS Hanna Czenczek
2023-10-05 17:08 ` Stefan Hajnoczi
2023-10-05 17:15 ` Michael S. Tsirkin
2023-10-06 7:48 ` [Virtio-fs] (no subject) Hanna Czenczek
2023-10-06 8:45 ` Michael S. Tsirkin
2023-10-06 9:15 ` Hanna Czenczek
2023-10-06 9:26 ` Michael S. Tsirkin
2023-10-06 9:47 ` Hanna Czenczek
2023-10-06 10:34 ` Michael S. Tsirkin
2023-10-06 11:42 ` Hanna Czenczek
2023-10-06 15:17 ` Alex Bennée
2023-10-06 15:47 ` Hanna Czenczek
2023-10-06 20:49 ` Alex Bennée
2023-10-09 8:07 ` Hanna Czenczek
2023-10-07 2:22 ` Yajun Wu
2023-10-09 8:21 ` Hanna Czenczek
2023-10-09 9:07 ` Hanna Czenczek
2023-10-09 9:13 ` Hanna Czenczek
2023-10-10 4:00 ` Yajun Wu
2023-10-10 8:18 ` Hanna Czenczek
2023-10-10 10:36 ` Alex Bennée [this message]
2023-10-10 13:18 ` Hanna Czenczek
2023-10-10 14:35 ` Alex Bennée
2023-10-13 18:02 ` Hanna Czenczek
2023-10-17 7:49 ` Viresh Kumar
2023-10-17 8:13 ` Hanna Czenczek
2023-10-09 10:28 ` German Maglione
2023-10-10 2:56 ` Yajun Wu
2023-10-10 10:04 ` German Maglione
2023-10-04 12:58 ` [PATCH v4 2/8] vhost-user.rst: Improve [GS]ET_VRING_BASE doc Hanna Czenczek
2023-10-05 17:38 ` Stefan Hajnoczi
2023-10-06 7:53 ` [Virtio-fs] " Hanna Czenczek
2023-10-06 8:49 ` Michael S. Tsirkin
2023-10-06 13:55 ` Hanna Czenczek
2023-10-06 13:58 ` Hanna Czenczek
2023-10-07 21:29 ` Michael S. Tsirkin
2023-10-07 21:27 ` Michael S. Tsirkin
2023-10-04 12:58 ` [PATCH v4 3/8] vhost-user.rst: Clarify enabling/disabling vrings Hanna Czenczek
2023-10-05 17:43 ` Stefan Hajnoczi
2023-10-18 12:14 ` Michael S. Tsirkin
2023-10-18 16:17 ` Hanna Czenczek
2023-10-04 12:59 ` [PATCH v4 4/8] vhost-user.rst: Introduce suspended state Hanna Czenczek
2023-10-05 17:44 ` Stefan Hajnoczi
2023-10-04 12:59 ` [PATCH v4 5/8] vhost-user.rst: Migrating back-end-internal state Hanna Czenczek
2023-10-05 17:46 ` Stefan Hajnoczi
2023-10-04 12:59 ` [PATCH v4 6/8] vhost-user: Interface for migration state transfer Hanna Czenczek
2023-10-05 17:46 ` Stefan Hajnoczi
2023-10-04 12:59 ` [PATCH v4 7/8] vhost: Add high-level state save/load functions Hanna Czenczek
2023-10-05 17:46 ` Stefan Hajnoczi
2023-10-04 12:59 ` [PATCH v4 8/8] vhost-user-fs: Implement internal migration Hanna Czenczek
2023-10-05 17:46 ` Stefan Hajnoczi
2023-10-05 17:48 ` [PATCH v4 0/8] vhost-user: Back-end state migration Stefan Hajnoczi
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=87lecapxi4.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=antonkuchin@yandex-team.ru \
--cc=eperezma@redhat.com \
--cc=hreitz@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=qemu-devel@nongnu.org \
--cc=virtio-fs@redhat.com \
--cc=yajunw@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).