Re: [virtio-dev] virtio-snd and snapshots (e.g. in QEMU) when audio is active
On Fri, Jul 21, 2023 at 12:44 AM Matias Ezequiel Vara Larsen wrote: > > Could you please advise what a device is expected to do in this case? > > > > Do you mean what a VMM shall do when taking a snapshot regarding the > virtio-snd device? Thank you for looking into this, Matias. Stefan already pointed to use qemu_put_virtqueue_element to save unprocessed messages in virtio-snd when taking a snapshot. Regards, Roman. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] virtio-snd and snapshots (e.g. in QEMU) when audio is active
On Thu, Jul 20, 2023 at 8:41 AM Stefan Hajnoczi wrote: > > Could you please advise what a device is expected to do in this case? > > Do you mean QEMU's VirtQueueElement? There are devices in QEMU that > save/load in-flight VirtQueueElements. See qemu_put_virtqueue_element(). Thank you, Stefan. I found examples on how to use qemu_put_virtqueue_element. This is clear now. Regards, Roman. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] RE: [virtio-comment] Re: [virtio-dev] [virtio 1.3] Feature freeze has started
> From: virtio-comm...@lists.oasis-open.org open.org> On Behalf Of Cornelia Huck
> Sent: Friday, July 21, 2023 9:09 AM
> > https://github.com/oasis-tcs/virtio-spec/issues/170 ("The size of
> > virtio_net_hdr struct are wrong when VIRTIO_NET_HASH_REPORT feature is
> > negotiated.")
> > * Can someone please check the status of this? Looks like a patch is
> >available, but no progress for a long time? Is this maybe interacting
> >with the inner header hash feature?
> >
> > Any others that I have missed?
>
> Last call for 1.3. The first two are done now, the third one has not seen any
> action, so if anything, it's going to be post-1.3.
>
> I think we're good (and can start preparing for the next steps).
>
Yes, we can do post 1.3.
The fix needs more words than what was posted. I will post one when the branch
opens.
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] RE: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
> From: Michael S. Tsirkin > Sent: Friday, July 21, 2023 8:42 AM > Yea, makes sense. > I think we are all set WRT what we planned to be in 1.3 - right? > Next step is preparing the changelog and packaging it all as WD, then voting > to > approve it as a CSD/CSPRD and start public review. > > Have time this week? if not I will get to it next week. Let me know what to do for change log prep and I can prepare it today. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev][PATCH 2/2] virtio-spi: add the device specification
Hello, is there already some virtio SPI Linux driver published to the public to have a chance to look at? Same question for the device side. Is there a qemu device (or something for a different virtualization environment like kvmtool) already published to the public anywhere? The spec made the impression that it's in an early stage so I expect there is nothing yet but I may be wrong with my assumption. On 17.04.23 16:03, Haixu Cui wrote: virtio-spi is a virtual SPI master and it allows a guset to operate and use the physical SPI master controlled by the host. --- device-types/spi/description.tex| 155 device-types/spi/device-conformance.tex | 7 ++ device-types/spi/driver-conformance.tex | 7 ++ 3 files changed, 169 insertions(+) create mode 100644 device-types/spi/description.tex create mode 100644 device-types/spi/device-conformance.tex create mode 100644 device-types/spi/driver-conformance.tex Regards Harald Mommer - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] [virtio 1.3] Feature freeze has started
On Mon, Jul 03 2023, Cornelia Huck wrote:
> As outlined in
> https://lists.oasis-open.org/archives/virtio/202304/msg00036.html ff.,
> as part of the release process for the 1.3 version of the virtio spec,
> we have now entered feature freeze. This means:
>
> ***
> By July 1st[3rd], all not yet integrated features that are targeting 1.3 need
> to have at least a github issue open that is pointing to a patch (set)
> on the list.
> ***
>
> AFAICS, the list of features matching these criteria is the following:
>
> https://github.com/oasis-tcs/virtio-spec/issues/173 ("virtio-net:
> support inner header hash")
> * this looks very close, with voting likely to start in the next
> couple of days
>
> https://github.com/oasis-tcs/virtio-spec/issues/167 ("Support
> transitional device for PCIe VF")
> * I have not followed that one in detail, but it has been stated that
> this one should also be ready soon -- can people please confirm that
> this will be ready for inclusion in July?
>
> https://github.com/oasis-tcs/virtio-spec/issues/170 ("The size of
> virtio_net_hdr struct are wrong when VIRTIO_NET_HASH_REPORT feature is
> negotiated.")
> * Can someone please check the status of this? Looks like a patch is
>available, but no progress for a long time? Is this maybe interacting
>with the inner header hash feature?
>
> Any others that I have missed?
Last call for 1.3. The first two are done now, the third one has not
seen any action, so if anything, it's going to be post-1.3.
I think we're good (and can start preparing for the next steps).
>
> I'd like to wrap this up in July; not a real problem if we spill over
> a couple of days into August, but I'd really like to avoid delaying the
> process for too much (it will take long enough already.)
>
> virtio 1.3 timeline:
>
> Development
>
> July 3rd: feature freeze (github issue <-- we are here
> and change on list)
>
> August 1st: change freeze (all voted
> upon)
>
> virtio-next development branch opens
>
> August: prepare draft
>
> August 31st (latest): draft voted upon by TC
>
> September: public review period
>
> October: addtl public review period, if needed
>
> October (November): 1.3 released
>
> merge virtio-next development branch
>
>
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: 1.3 and branching
On Fri, Jul 21 2023, "Michael S. Tsirkin" wrote: > On Fri, Jul 21, 2023 at 02:24:57PM +0200, Cornelia Huck wrote: >> On Wed, Jul 12 2023, "Michael S. Tsirkin" wrote: >> >> > On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote: >> >> On Wed, Jul 12 2023, "Michael S. Tsirkin" wrote: >> >> > Yes we were supposed to freeze for 1.3. This change can be merged on a >> >> > main branch after 1.3 forks and is under review. >> >> >> >> Nod, that's what I would prefer to do. Being merged on virtio-next >> >> should be enough for including device/driver implementations. >> > >> > Except I'd prefer a v1.3 branch instead of a next branch - adding things >> > on the branch should be harder, not easier. >> >> Just to clarify: What I had planned for 1.3 (and what we already did for >> 1.2) is to fork a -next branch, finish 1.3 on the master branch, and >> then merge -next back into master after we'd be done with 1.3. >> >> I'm not sure what you mean by "adding things on the branch should be >> harder, not easier" -- I think it is already a bit harder because it is >> a branch :) >> >> We can of course do a v1.3 branch instead and continue developing on >> master, but shouldn't we then create branches (glorified tags) for the >> older releases as well? > > Yea, makes sense. > I think we are all set WRT what we planned to be in 1.3 - right? I'll send out a "last call" JFTR, but I think we're good. > Next step is preparing the changelog and packaging it > all as WD, then voting to approve it as a CSD/CSPRD and start > public review. > > Have time this week? if not I will get to it next week. Certainly not this week, but one of us can get started with the changelog next week. Fortunately, it should be shorter than the one for 1.2 :) - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
On Fri, Jul 21, 2023 at 02:24:57PM +0200, Cornelia Huck wrote: > On Wed, Jul 12 2023, "Michael S. Tsirkin" wrote: > > > On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote: > >> On Wed, Jul 12 2023, "Michael S. Tsirkin" wrote: > >> > Yes we were supposed to freeze for 1.3. This change can be merged on a > >> > main branch after 1.3 forks and is under review. > >> > >> Nod, that's what I would prefer to do. Being merged on virtio-next > >> should be enough for including device/driver implementations. > > > > Except I'd prefer a v1.3 branch instead of a next branch - adding things > > on the branch should be harder, not easier. > > Just to clarify: What I had planned for 1.3 (and what we already did for > 1.2) is to fork a -next branch, finish 1.3 on the master branch, and > then merge -next back into master after we'd be done with 1.3. > > I'm not sure what you mean by "adding things on the branch should be > harder, not easier" -- I think it is already a bit harder because it is > a branch :) > > We can of course do a v1.3 branch instead and continue developing on > master, but shouldn't we then create branches (glorified tags) for the > older releases as well? Yea, makes sense. I think we are all set WRT what we planned to be in 1.3 - right? Next step is preparing the changelog and packaging it all as WD, then voting to approve it as a CSD/CSPRD and start public review. Have time this week? if not I will get to it next week. -- MST - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] 1.3 and branching (was: [virtio-dev] Re: [PATCH v12] virtio-net: support device stats)
On Wed, Jul 12 2023, "Michael S. Tsirkin" wrote: > On Wed, Jul 12, 2023 at 02:24:32PM +0200, Cornelia Huck wrote: >> On Wed, Jul 12 2023, "Michael S. Tsirkin" wrote: >> > Yes we were supposed to freeze for 1.3. This change can be merged on a >> > main branch after 1.3 forks and is under review. >> >> Nod, that's what I would prefer to do. Being merged on virtio-next >> should be enough for including device/driver implementations. > > Except I'd prefer a v1.3 branch instead of a next branch - adding things > on the branch should be harder, not easier. Just to clarify: What I had planned for 1.3 (and what we already did for 1.2) is to fork a -next branch, finish 1.3 on the master branch, and then merge -next back into master after we'd be done with 1.3. I'm not sure what you mean by "adding things on the branch should be harder, not easier" -- I think it is already a bit harder because it is a branch :) We can of course do a v1.3 branch instead and continue developing on master, but shouldn't we then create branches (glorified tags) for the older releases as well? - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] virtio-snd and snapshots (e.g. in QEMU) when audio is active
Hello Roman, On Wed, Jul 19, 2023 at 04:21:08PM -0700, Roman Kiryanov wrote: > Hi, > > I work in Android Studio Emulator and we use virtio-snd (implemented > ourselves) for audio output/input. According to the spec (1.2), the > device has one TX virtqueue for all output streams and one RX > virtqueue for all input streams. Each stream may and usually have more > than one period (I request 4 periods). > > Because virtqueues are shared between streams (if there are more than > one stream in the same direction), I cannot fetch vq messages when a > stream needs one. I fetch vq messages (and put them into my own buffer > to process them later) when the kernel puts them into a vq. I hope > this is correct. I think this is correct. If I understand correctly, this is the idea of the pre-buffering after the PREPARE command, i.e., to feed the audio engine before to START streaming (see section 5.14.6.6.1 PCM Command Lifecycle). > I think I tried processing them immediately (at least > for TX) but the kernel was not happy with this because I was draining > the buffer too fast causing XRUN. > If a snapshot request comes when audio streams are active I may have > several unprocessed messages for several streams for both TX and RX. > In my case messages are VirtQueueElement* which I don't think can be > saved directly. > > Could you please advise what a device is expected to do in this case? > Do you mean what a VMM shall do when taking a snapshot regarding the virtio-snd device? Matias - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
