From: Pankaj Gupta <pagupta@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, jasowang@redhat.com, amit@kernel.org
Subject: [virtio-dev] Re: [PATCH] content: document console vq detach buffer
Date: Mon, 19 Aug 2019 06:19:52 -0400 (EDT) [thread overview]
Message-ID: <2032516350.9204869.1566209992338.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20190814104253-mutt-send-email-mst@kernel.org>
>
> On Tue, Aug 13, 2019 at 06:21:33PM +0530, Pankaj Gupta wrote:
> > This patch documents console special case where vq buffers
> > are deleted at port hotunplug time. This behavior is different in
> > other devices where vq buffers are deleted at device unplug time.
> >
> > Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> > ---
> > content.tex | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/content.tex b/content.tex
> > index ee0d7c9..33e8ccc 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -497,6 +497,8 @@ \section{Device Cleanup}\label{sec:General
> > Initialization And Device Operation /
> > of a live virtqueue.
> >
> > Thus a driver MUST ensure a virtqueue isn't live (by device reset) before
> > removing exposed buffers.
> > +Console has a special property that when port is detached virtqueue is
> > considered stopped, device
> > +must not use any buffers, and it is legal to take buffers out of the
> > device.
> >
> > \chapter{Virtio Transport Options}\label{sec:Virtio Transport Options}
>
> I don't think that's enough, or a good way to do it.
>
> The assumption that once exposed buffers stay exposed until used
> is spread out in lots of places in the spec.
oh... I did not notice the other places.
> E.g.
> 2.6.6.1
> Driver Requirements: The Virtqueue Available Ring
> A driver MUST NOT decrement the available idx on a virtqueue (ie. there is
> no way to “unexpose” buffers).
>
> And in the packed ring part, e.g.
>
> A device MUST NOT use a descriptor unless it observes the VIRTQ_DESC_F_AVAIL
> bit in its flags
> being changed (e.g. as compared to the initial zero value). A device MUST
> NOT change a descriptor after
> changing it’s the VIRTQ_DESC_F_USED bit in its flags.
> 2.7.16
> Driver Requirements: The Virtqueue Descriptor Table
> A driver MUST NOT change a descriptor unless it observes the
> VIRTQ_DESC_F_USED bit in its flags being
> changed. A driver MUST NOT change a descriptor after changing the
> VIRTQ_DESC_F_AVAIL bit in its flags.
>
> So we need to document how exactly to revert added buffers in all
> these places. I propose adding special sections, explaining
> that some devices allow taking back available buffers.
Sure.
>
> We need to see how this interacts with other places in the spec:
> e.g. if we do allow taking back buffers, what happens with notifications
> such as when using event index? Are they resent when buffer is
> re-added?
o.k. Will check this.
>
>
> I also worry that since the spec said this can't happen, some
> hypervisors might implement a policy that will crash if the guest
> violates this rule. Seems unlikely since Linux violated the rule for a
> while, but I'd suggest that you take a look at least at some open-source
> hypervisors to see what is going on.
Good point. I will check.
An alternative is a feature flag -
> if we do that I would actually advocate for a generic feature that
> allows stopping queues at any time, then restarting it. I think it would
> be handy generally for things like enabling/disabling XDP.
o.k. Good idea. Generic queue stopping will require additional work
e.g draining the queue and might require certain device specific operation.
Will look at this.
Thank you for the suggestions.
Best regards,
Pankaj
>
>
>
> > --
> > 2.21.0
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
prev parent reply other threads:[~2019-08-19 10:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-13 12:51 [virtio-dev] [PATCH] content: document console vq detach buffer Pankaj Gupta
2019-08-13 15:21 ` Stefan Hajnoczi
2019-08-14 6:33 ` Pankaj Gupta
2019-08-14 10:16 ` Stefan Hajnoczi
2019-08-18 11:49 ` [virtio-dev] " Michael S. Tsirkin
2019-08-19 10:19 ` Pankaj Gupta [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=2032516350.9204869.1566209992338.JavaMail.zimbra@redhat.com \
--to=pagupta@redhat.com \
--cc=amit@kernel.org \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox