kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: rusty@rustcorp.com.au, habanero@linux.vnet.ibm.com,
	Shirley Ma <mashirle@us.ibm.com>,
	Krishna Kumar2 <krkumar2@in.ibm.com>,
	kvm@vger.kernel.org, steved@us.ibm.com,
	Tom Lendacky <tahm@linux.vnet.ibm.com>,
	borntraeger@de.ibm.com
Subject: Re: [PATCH] virtio-spec: 64 bit features, used/avail event
Date: Mon, 02 May 2011 17:44:36 +0300	[thread overview]
Message-ID: <4DBEC354.5020101@redhat.com> (raw)
In-Reply-To: <20110502131739.GA23143@redhat.com>

On 05/02/2011 04:17 PM, Michael S. Tsirkin wrote:
> I'm working on a patchset that modified the notificatin
> hand-off in virtio to be basically like Xen:
> each side published an index, the other side only triggers
> an event when it crosses that index value
> (Xen event indexes start at 1, ours start at 0 for
> backward-compatiblity, but that's minor).
>
> Especially for testing, it is very convenient to have
> separate feature bits for this change in used and available
> ring; since we've run out of bits in the 32 bit field,
> I added another 32 bit and bit 31 enables that.
>

> -30 Feature bits reserved for extensions to the queue mechanism
> +
> +\change_inserted 0 1304329326
> +4
> +\change_deleted 0 1304329325
> +3
> +\change_unchanged
> +0 Feature bits reserved for extensions to the queue mechanism

That would be 24 to 30, 32 to 40.

> +\change_inserted 0 1304329351
> +
> +\end_layout
> +
> +\begin_layout Description
> +
> +\change_inserted 0 1304329398
> +41
> +\begin_inset space ~
> +\end_inset
> +
> +to
> +\begin_inset space ~
> +\end_inset
> +
> +63 Feature bits reserved for future extensions
>   \end_layout
>
>
> @@ -1891,7 +2118,38 @@ flags
>
>    field is currently 0 or 1: 1 indicating that we do not need an interrupt
>    when the device consumes a descriptor from the available ring.
> - This interrupt suppression is merely an optimization; it may not suppress
> +
> +\change_inserted 0 1304331587
> +Alternatively, we can ask the device to delay interrupts until an entry

we can ask -> the guest may ask

> + with an index specified by the
> +\begin_inset Quotes eld
> +\end_inset
> +
> +used_event
> +\begin_inset Quotes erd
> +\end_inset
> +
> + field is written in the used ring (equivalently, until the
> +\emph on
> +idx
> +\emph default
> + field in the used ring will reach the value
> +\emph on
> +used_event + 1
> +\emph default
> +).
> + The method employed by the device is controlled by the VIRTIO_RING_F_USED_EVENT
> +_IDX feature bit (see
> +\begin_inset CommandInset ref
> +LatexCommand ref
> +reference "cha:Reserved-Feature-Bits"
> +
> +\end_inset
> +
> +).
> +
> +\change_unchanged
> +This interrupt suppression is merely an optimization; it may not suppress
>    interrupts entirely.
>   \end_layout

This section is strangely worded, from the guest point of view, which is 
strange for the device spec.  It's better to say things explicitly.  
However, this issue is not introduced by the patch.

>
> @@ -1940,6 +2198,17 @@ struct vring_avail {
>   \begin_layout Plain Layout
>
>      u16 ring[qsz]; /* qsz is the Queue Size field read from device */
> +\change_inserted 0 1304329945
> +
> +\end_layout
> +
> +\begin_layout Plain Layout
> +
> +\change_inserted 0 1304329957
> +
> +   u16 used_event;
> +\change_unchanged
> +
>   \end_layout
>
>   \begin_layout Plain Layout
> @@ -1963,8 +2232,63 @@ The used ring is where the device returns buffers once it is done with them.
>   \emph on
>   available
>   \emph default
> - ring (the flag is kept here because this is the only part of the virtqueue
> - written by the device).
> + ring
> +\change_inserted 0 1304331253
> +.
> + Alternatively, the device can hint that no notification is necessary until

the guest can request the device to hint


-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2011-05-02 14:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-02 13:17 [PATCH] virtio-spec: 64 bit features, used/avail event Michael S. Tsirkin
2011-05-02 14:44 ` Avi Kivity [this message]
2011-05-02 15:10   ` Michael S. Tsirkin

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=4DBEC354.5020101@redhat.com \
    --to=avi@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=habanero@linux.vnet.ibm.com \
    --cc=krkumar2@in.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=mashirle@us.ibm.com \
    --cc=mst@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=steved@us.ibm.com \
    --cc=tahm@linux.vnet.ibm.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).