[virtio-dev] VIRTIO adoption in other hypervisors

[virtio-dev] VIRTIO adoption in other hypervisors

[Alex Bennée]

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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: VIRTIO adoption in other hypervisors

[Jan Kiszka]

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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: VIRTIO adoption in other hypervisors

[Jan Kiszka]

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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: VIRTIO adoption in other hypervisors

[Alex Bennée]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 28.02.20 11:30, Jan Kiszka wrote:
>> On 28.02.20 11:16, Alex Bennée wrote:
>>> Hi,
>>>
<snip>
>>> 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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

[virtio-dev] Re: VIRTIO adoption in other hypervisors

[Jan Kiszka]

On 28.02.20 17:47, Alex Bennée wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 28.02.20 11:30, Jan Kiszka wrote:
>>> On 28.02.20 11:16, Alex Bennée wrote:
>>>> Hi,
>>>>
> <snip>
>>>> 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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

Re: [virtio-dev] VIRTIO adoption in other hypervisors

[Paolo Bonzini]

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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

Re: [virtio-dev] VIRTIO adoption in other hypervisors

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> 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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

Re: [virtio-dev] VIRTIO adoption in other hypervisors

[Paolo Bonzini]

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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

Re: [virtio-dev] VIRTIO adoption in other hypervisors

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Fri, Feb 28, 2020 at 10:16:21AM +0000, 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]