[virtio-dev] Re: VIRTIO adoption in other hypervisors
On 28.02.20 17:47, Alex Bennée wrote: Jan Kiszka writes: On 28.02.20 11:30, Jan Kiszka wrote: On 28.02.20 11:16, Alex Bennée wrote: Hi, I believe there has been some development work for supporting VIRTIO on Xen although it seems to have stalled according to: https://wiki.xenproject.org/wiki/Virtio_On_Xen Recently at KVM Forum there was Jan's talk about Inter-VM shared memory which proposed ivshmemv2 as a VIRTIO transport: https://events19.linuxfoundation.org/events/kvm-forum-2019/program/schedule/ As I understood it this would allow Xen (and other hypervisors) a simple way to be able to carry virtio traffic between guest and end point. And to clarify the scope of this effort: virtio-over-ivshmem is not the fastest option to offer virtio to a guest (static "DMA" window), but it is the simplest one from the hypervisor PoV and, thus, also likely the easiest one to argue over when it comes to security and safety. So to drill down on this is this a particular problem with type-1 hypervisors? Well, this typing doesn't help here (like it rarely does). There are kvm-based setups that are stripped down and hardened in a way where other folks would rather think of "type 1". I just had a discussion around such a model for a cloud scenario that runs on kvm. It seems to me any KVM-like run loop trivially supports a range of virtio devices by virtue of trapping accesses to the signalling area of a virtqueue and allowing the VMM to handle the transaction which ever way it sees fit. I've not quite understood the way Xen interfaces to QEMU aside from it's different to everything else. More over it seems the type-1 hypervisors are more interested in providing better isolation between segments of a system whereas VIRTIO currently assumes either the VMM or the hypervisor has full access the full guest address space. I've seen quite a lot of slides that want to isolate sections of device emulation to separate processes or even separate guest VMs. The point is in fact not only whether to trap IO accesses or to ask the guest to rather target something like ivshmem (in fact, that is where use cases I have in mind deviated from those of that cloud operator). It is specifically the question how the backend should be able to transfer data to/from the frontend. If you want to isolate the both from each other (driver VMs/domains/etc.), you either need a complex virtual IOMMU (or "grant tables") or a static DMA windows (like ivshmem). The former is more efficient with large transfers, the latter is much simpler and therefore more robust. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux - 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 adoption in other hypervisors
Jan Kiszka writes: > On 28.02.20 11:30, Jan Kiszka wrote: >> On 28.02.20 11:16, Alex Bennée wrote: >>> Hi, >>> >>> I believe there has been some development work for supporting VIRTIO on >>> Xen although it seems to have stalled according to: >>> >>>https://wiki.xenproject.org/wiki/Virtio_On_Xen >>> >>> Recently at KVM Forum there was Jan's talk about Inter-VM shared memory >>> which proposed ivshmemv2 as a VIRTIO transport: >>> >>> >>> https://events19.linuxfoundation.org/events/kvm-forum-2019/program/schedule/ >>> >>> >>> >>> As I understood it this would allow Xen (and other hypervisors) a simple >>> way to be able to carry virtio traffic between guest and end point. > > And to clarify the scope of this effort: virtio-over-ivshmem is not > the fastest option to offer virtio to a guest (static "DMA" window), > but it is the simplest one from the hypervisor PoV and, thus, also > likely the easiest one to argue over when it comes to security and > safety. So to drill down on this is this a particular problem with type-1 hypervisors? It seems to me any KVM-like run loop trivially supports a range of virtio devices by virtue of trapping accesses to the signalling area of a virtqueue and allowing the VMM to handle the transaction which ever way it sees fit. I've not quite understood the way Xen interfaces to QEMU aside from it's different to everything else. More over it seems the type-1 hypervisors are more interested in providing better isolation between segments of a system whereas VIRTIO currently assumes either the VMM or the hypervisor has full access the full guest address space. I've seen quite a lot of slides that want to isolate sections of device emulation to separate processes or even separate guest VMs. -- Alex Bennée - 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 adoption in other hypervisors
On 28/02/20 12:18, Alex Bennée wrote: >> OS X Hypervisor.framework just uses QEMU, so it can use virtio devices >> too. VirtualBox also supports virtio devices. > I guess these don't do any sort of vhost support so all virtio devices > are handled directly in QEMU? OS X can use vhost-user. Paolo - 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 adoption in other hypervisors
Paolo Bonzini writes: > On 28/02/20 11:16, Alex Bennée wrote: >> - How about HyperV and the OSX equivalent? > > OS X Hypervisor.framework just uses QEMU, so it can use virtio devices > too. VirtualBox also supports virtio devices. I guess these don't do any sort of vhost support so all virtio devices are handled directly in QEMU? -- Alex Bennée - 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] Re: [PATCH v5] virtio-snd: add virtio sound device specification
On Thu, Feb 27, 2020 at 03:08:59PM +0100, Anton Yakovlev wrote: > Hello all, > > We have completed the implementation of the PoC specification v5. Below are > our comments on what might or should be improved in the specification. > > Initialization: > > 1. I think we should add the direction of the jack (in/out) to the > configuration of the jack. Because some properties (for example, a label for > some jack types) are based on this direction. The Linux HDA subsystem takes > this information from a pin/complex configuration. But we don't have (and > don't need) such entities. Sounds good. > 2. The stream configuration contains “features” that partially work as normal > virtio features, and partially do not. Maybe it is better to rename the field > to “flags” (as well as in the set_params request) and enter two sets of flags: > one is reported in the stream configuration, and the other is used in the > set_params request? This should make things less confusing. Maybe have both features and flags fields? > 1. In the latest version of the specification, we resized the “features” field > in the stream configuration (u8->le32), but forgot to do the same in the > set_params request. This should be fixed. Sure. > 2. The device may report polling support for message-based transport. In this > case, the driver can be optimized so that it does not kick virtqueue for each > message. Makes sense too, especially given that the packets should arrive at regular intervals and not (unlike for example network packets) at unpredictable times. > 3. For the input stream (capture), we decided to report the actual filled size > using the len field in the virtqueue descriptor. Should the specification > clearly indicate that the value contains sizeof(struct virtio_snd_pcm_status) > + the size of the recorded frames? Doesn't hurt to explicitly say so even though it should be clear that the descriptor size covers the complete payload and not only the recorded frames. > 4. We also need to add a device requirement to complete all pending messages > for a stream on a RELEASE request. Otherwise, they may become stuck in the > virtqueue. Yes, that makes sense. Maybe also explicitly say that the RELEASE request should be completed last (only after all other pending messages are completed). cheers, Gerd - 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 adoption in other hypervisors
On Fri, Feb 28, 2020 at 10:16:21AM +, Alex Bennée wrote: > I'm currently trying to get my head around virtio and was wondering how > widespread adoption of virtio is amongst the various hypervisors and > emulators out there. > > Obviously I'm familiar with QEMU both via KVM and even when just doing > plain emulation (although with some restrictions). As far as I'm aware > the various Rust based VMMs have vary degrees of support for virtio > devices over KVM as well. CrosVM specifically is embracing virtio for > multi-process device emulation. > > I believe there has been some development work for supporting VIRTIO on > Xen although it seems to have stalled according to: > > https://wiki.xenproject.org/wiki/Virtio_On_Xen > > Recently at KVM Forum there was Jan's talk about Inter-VM shared memory > which proposed ivshmemv2 as a VIRTIO transport: > > https://events19.linuxfoundation.org/events/kvm-forum-2019/program/schedule/ > > As I understood it this would allow Xen (and other hypervisors) a simple > way to be able to carry virtio traffic between guest and end point. > > So some questions: > > - Am I missing anything out in that summary? VirtualBox has virtio-net support: https://www.virtualbox.org/manual/ch06.html > - How about HyperV and the OSX equivalent? macOS has *guest* drivers for VIRTIO devices: https://www.kraxel.org/blog/2019/06/macos-qemu-guest/ Stefan signature.asc Description: PGP signature
Re: [virtio-dev] VIRTIO adoption in other hypervisors
On 28/02/20 11:16, Alex Bennée wrote: > - How about HyperV and the OSX equivalent? OS X Hypervisor.framework just uses QEMU, so it can use virtio devices too. VirtualBox also supports virtio devices. Paolo - 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 adoption in other hypervisors
On 28.02.20 11:30, Jan Kiszka wrote: On 28.02.20 11:16, Alex Bennée wrote: Hi, I'm currently trying to get my head around virtio and was wondering how widespread adoption of virtio is amongst the various hypervisors and emulators out there. Obviously I'm familiar with QEMU both via KVM and even when just doing plain emulation (although with some restrictions). As far as I'm aware the various Rust based VMMs have vary degrees of support for virtio devices over KVM as well. CrosVM specifically is embracing virtio for multi-process device emulation. I believe there has been some development work for supporting VIRTIO on Xen although it seems to have stalled according to: https://wiki.xenproject.org/wiki/Virtio_On_Xen Recently at KVM Forum there was Jan's talk about Inter-VM shared memory which proposed ivshmemv2 as a VIRTIO transport: https://events19.linuxfoundation.org/events/kvm-forum-2019/program/schedule/ As I understood it this would allow Xen (and other hypervisors) a simple way to be able to carry virtio traffic between guest and end point. And to clarify the scope of this effort: virtio-over-ivshmem is not the fastest option to offer virtio to a guest (static "DMA" window), but it is the simplest one from the hypervisor PoV and, thus, also likely the easiest one to argue over when it comes to security and safety. Jan So some questions: - Am I missing anything out in that summary? - How about HyperV and the OSX equivalent? - Do any other type-1 hypervisors support virtio? From the top of my head, some other hypervisors with virtio support (irrespective of any classification): https://wiki.freebsd.org/bhyve https://projectacrn.org/ http://www.xhypervisor.org/ https://www.opensynergy.com/automotive-hypervisor/ But there are likely more. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux - 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] [RFC] Upstreaming virtio-wayland (or an alternative)
On Fri, 28 Feb 2020 19:11:40 +0900
David Stevens wrote:
> > > > Yes, sure, we need to exactly specify the different kinds of file
> > > > handles / resources. I think it makes sense to have a virtio feature
> > > > flag for each of them, so guest+host can easily negotiate what they are
> > > > able to handle and what not.
> > >
> > > I was expecting that to be a feature of the resource producers
> > > (virtio-gpu, virtio-fs, ...) rather than a feature of virtio-ipc
> > > itself.
> >
> > "resources from other virtio devices" would be one virtio-ipc feature
> > flag. And, yes, that would for the most part have the other device
> > handle the problem.
> >
> > But there also is "unix socket", or maybe a somewhat broader "stream",
> > which would be another feature flag I guess because virtio-ipc would
> > just tunnel the stream without the help from other devices.
>
> Can you elaborate on what you mean by this? I can envision how
> virtio-ipc would be a generic mechanism for passing data+virtio
> resources, including any new types of resources it itself defines.
> However, if "unix sockets" or a generic "stream" expands beyond
> virtio, that seems too broad, with too many edge cases to be feasible
> to implement.
I don't think we need to bridge unix sockets or any kind of stream
interface, like pipes, regular sockets, ... in kernel space. If
virtio-ipc provides a way to create anonymous virtio-ipc connections
whose FDs can be passed to a opened virtio-ipc connection, we can
implement those bridges in user space. fstat() allows us to know what
kind of FD we're receiving from the unix socket (socket, regular
file, fifo), and for sockets, we even have
getsockopt({SO_DOMAIN,SO_TYPE}) to get a more precise information.
-
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] [RFC] Upstreaming virtio-wayland (or an alternative)
On Fri, Feb 28, 2020 at 07:11:40PM +0900, David Stevens wrote: > > But there also is "unix socket", or maybe a somewhat broader "stream", > > which would be another feature flag I guess because virtio-ipc would > > just tunnel the stream without the help from other devices. > > Can you elaborate on what you mean by this? I can envision how > virtio-ipc would be a generic mechanism for passing data+virtio > resources, including any new types of resources it itself defines. > However, if "unix sockets" or a generic "stream" expands beyond > virtio, that seems too broad, with too many edge cases to be feasible > to implement. As far I know this is exactly what virtio-wayland does today if you try to pass a unix socket file descriptor to the other side, so I assume this functionality is needed ... cheers, Gerd - 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 adoption in other hypervisors
On 28.02.20 11:16, Alex Bennée wrote: Hi, I'm currently trying to get my head around virtio and was wondering how widespread adoption of virtio is amongst the various hypervisors and emulators out there. Obviously I'm familiar with QEMU both via KVM and even when just doing plain emulation (although with some restrictions). As far as I'm aware the various Rust based VMMs have vary degrees of support for virtio devices over KVM as well. CrosVM specifically is embracing virtio for multi-process device emulation. I believe there has been some development work for supporting VIRTIO on Xen although it seems to have stalled according to: https://wiki.xenproject.org/wiki/Virtio_On_Xen Recently at KVM Forum there was Jan's talk about Inter-VM shared memory which proposed ivshmemv2 as a VIRTIO transport: https://events19.linuxfoundation.org/events/kvm-forum-2019/program/schedule/ As I understood it this would allow Xen (and other hypervisors) a simple way to be able to carry virtio traffic between guest and end point. So some questions: - Am I missing anything out in that summary? - How about HyperV and the OSX equivalent? - Do any other type-1 hypervisors support virtio? From the top of my head, some other hypervisors with virtio support (irrespective of any classification): https://wiki.freebsd.org/bhyve https://projectacrn.org/ http://www.xhypervisor.org/ https://www.opensynergy.com/automotive-hypervisor/ But there are likely more. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux - 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] VIRTIO adoption in other hypervisors
Hi, I'm currently trying to get my head around virtio and was wondering how widespread adoption of virtio is amongst the various hypervisors and emulators out there. Obviously I'm familiar with QEMU both via KVM and even when just doing plain emulation (although with some restrictions). As far as I'm aware the various Rust based VMMs have vary degrees of support for virtio devices over KVM as well. CrosVM specifically is embracing virtio for multi-process device emulation. I believe there has been some development work for supporting VIRTIO on Xen although it seems to have stalled according to: https://wiki.xenproject.org/wiki/Virtio_On_Xen Recently at KVM Forum there was Jan's talk about Inter-VM shared memory which proposed ivshmemv2 as a VIRTIO transport: https://events19.linuxfoundation.org/events/kvm-forum-2019/program/schedule/ As I understood it this would allow Xen (and other hypervisors) a simple way to be able to carry virtio traffic between guest and end point. So some questions: - Am I missing anything out in that summary? - How about HyperV and the OSX equivalent? - Do any other type-1 hypervisors support virtio? -- Alex Bennée - 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] [RFC] Upstreaming virtio-wayland (or an alternative)
> > > Yes, sure, we need to exactly specify the different kinds of file > > > handles / resources. I think it makes sense to have a virtio feature > > > flag for each of them, so guest+host can easily negotiate what they are > > > able to handle and what not. > > > > I was expecting that to be a feature of the resource producers > > (virtio-gpu, virtio-fs, ...) rather than a feature of virtio-ipc > > itself. > > "resources from other virtio devices" would be one virtio-ipc feature > flag. And, yes, that would for the most part have the other device > handle the problem. > > But there also is "unix socket", or maybe a somewhat broader "stream", > which would be another feature flag I guess because virtio-ipc would > just tunnel the stream without the help from other devices. Can you elaborate on what you mean by this? I can envision how virtio-ipc would be a generic mechanism for passing data+virtio resources, including any new types of resources it itself defines. However, if "unix sockets" or a generic "stream" expands beyond virtio, that seems too broad, with too many edge cases to be feasible to implement. -David - 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] [RFC] Upstreaming virtio-wayland (or an alternative)
Hi, > > Yes, sure, we need to exactly specify the different kinds of file > > handles / resources. I think it makes sense to have a virtio feature > > flag for each of them, so guest+host can easily negotiate what they are > > able to handle and what not. > > I was expecting that to be a feature of the resource producers > (virtio-gpu, virtio-fs, ...) rather than a feature of virtio-ipc > itself. "resources from other virtio devices" would be one virtio-ipc feature flag. And, yes, that would for the most part have the other device handle the problem. But there also is "unix socket", or maybe a somewhat broader "stream", which would be another feature flag I guess because virtio-ipc would just tunnel the stream without the help from other devices. Possibly there will be more ... cheers, Gerd - 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] [RFC] Upstreaming virtio-wayland (or an alternative)
Hi Gerd, On Thu, 27 Feb 2020 15:43:22 +0100 Gerd Hoffmann wrote: > Hi, > > > > > Can you provide more detail about the envisioned scope of this > > > > framework? > > > > > > The scope is "generic message+FD passing" interface, which is pretty > > > much what virtio-wl provides. > > > > I think that scope is too broad. A socket is a 'generic message+FD' > > interface. Unless there's the expectation that the interface should > > eventually be as flexible as a regular domain socket, I think it would > > be a good idea to frame the scope of the interface more precisely. > > Yes, sure, we need to exactly specify the different kinds of file > handles / resources. I think it makes sense to have a virtio feature > flag for each of them, so guest+host can easily negotiate what they are > able to handle and what not. I was expecting that to be a feature of the resource producers (virtio-gpu, virtio-fs, ...) rather than a feature of virtio-ipc itself. If we go for a model where UUID <-> resource/'struct file' mappings are created by the subsystems that are in charge of those resources, it's hard for virtio-ipc to know what kind of resources can be passed in advance. Regards, Boris - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
