Xen devel - Apr 2011 - Introduction to VirtIO on Xen project

Hi, all.

I''m Wei Liu, a graduate student from Wuhan University, Hubei, China.
I''m accepted to GSoC 2011 for Xen and responsible for the project
VirtIO on Xen. It''s my honor to get accepted and involved in this
wonderful community. I''ve been doing Xen development for my lab since
late 2009.

As you all know, VirtIO is a generic paravirtualized mainly used in
KVM now. But it should not be too hard to port VirtIO to Xen. When
done, Xen will have access to Linux kernel''s VirtIO interfaces and
developers will have an alternative way to deliver PV drivers besides
from the original ring buffer flavor. This project requires: Modify
upstream QEMU, replace KVM-specific interface with generic QEMU
function; Modify Xen / Xentools to support VirtIO; Modify Linux
kernel''s VirtIO interfaces.

We must take two usage scenarios into consideration:

1. PV-on-HVM;
2. Normal PV.

These two scenarios require working on different set of functions:

1. XenBus vs VirtualPCI, it''s about how to create a channel;
2. PV vs HVM, it''s about how events are handled.

Most of the code in VirtIO will be left as-it-is. But the notification
mechanism should be replaced with Xen''s event channel. This applies to
QEMU''s porting as well.

In the PV on HVM case, QEMU needs to use event channel to get / send
notification and foreign mapping / grant table functions in libxc
/libxl to map memory pages. Virtual PCI bus will be used to establish
a channel between Dom0 and DomU. In some sense, it makes no
differences on the Linux kernel side.

In the normal PV case, QEMU needs to use event channel to get / send
notification, and foreign mapping functions in libxc / libxl to map
memory pages. XenBus / Xenstore will be used to establish a channel
between Dom0 and DomU. Linux VirtIO driver should use Xen''s event
channel as kick / notify function.

When the porting is finished, I will carry on some performance tests
with standardized tools such as ioperf, netperf and kernbench.
Testsuites will be run on five different configurations:

1. Native Linux
2. Xen with PV-on-HVM VirtIO support
3. Xen with normal PV VirtIO support
4. Xen with original PV driver support
5. KVM with VirtIO support

A short report will be written based on the results.

This is a brief introduction to the project. Any comments are welcomed.


-- 
Best regards
Wei Liu
Twitter: @iliuw
Site: http://liuw.name

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Welcome!  This looks like a good project -- looking forward to seeing it done!

 -George

On Wed, Apr 27, 2011 at 3:53 AM, Wei Liu <liuw@liuw.name>
wrote:
> Hi, all.
>
> I''m Wei Liu, a graduate student from Wuhan University, Hubei,
China.
> I''m accepted to GSoC 2011 for Xen and responsible for the project
> VirtIO on Xen. It''s my honor to get accepted and involved in this
> wonderful community. I''ve been doing Xen development for my lab
since
> late 2009.
>
> As you all know, VirtIO is a generic paravirtualized mainly used in
> KVM now. But it should not be too hard to port VirtIO to Xen. When
> done, Xen will have access to Linux kernel''s VirtIO interfaces and
> developers will have an alternative way to deliver PV drivers besides
> from the original ring buffer flavor. This project requires: Modify
> upstream QEMU, replace KVM-specific interface with generic QEMU
> function; Modify Xen / Xentools to support VirtIO; Modify Linux
> kernel''s VirtIO interfaces.
>
> We must take two usage scenarios into consideration:
>
> 1. PV-on-HVM;
> 2. Normal PV.
>
> These two scenarios require working on different set of functions:
>
> 1. XenBus vs VirtualPCI, it''s about how to create a channel;
> 2. PV vs HVM, it''s about how events are handled.
>
> Most of the code in VirtIO will be left as-it-is. But the notification
> mechanism should be replaced with Xen''s event channel. This
applies to
> QEMU''s porting as well.
>
> In the PV on HVM case, QEMU needs to use event channel to get / send
> notification and foreign mapping / grant table functions in libxc
> /libxl to map memory pages. Virtual PCI bus will be used to establish
> a channel between Dom0 and DomU. In some sense, it makes no
> differences on the Linux kernel side.
>
> In the normal PV case, QEMU needs to use event channel to get / send
> notification, and foreign mapping functions in libxc / libxl to map
> memory pages. XenBus / Xenstore will be used to establish a channel
> between Dom0 and DomU. Linux VirtIO driver should use Xen''s event
> channel as kick / notify function.
>
> When the porting is finished, I will carry on some performance tests
> with standardized tools such as ioperf, netperf and kernbench.
> Testsuites will be run on five different configurations:
>
> 1. Native Linux
> 2. Xen with PV-on-HVM VirtIO support
> 3. Xen with normal PV VirtIO support
> 4. Xen with original PV driver support
> 5. KVM with VirtIO support
>
> A short report will be written based on the results.
>
> This is a brief introduction to the project. Any comments are welcomed.
>
>
> --
> Best regards
> Wei Liu
> Twitter: @iliuw
> Site: http://liuw.name
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

That''s why I am trying to run Fedora 14 on upstream-qemu +
xen-unstable.

On HVM domain, as SPICE worked with some libxl patches, I guess virtio-pci
should work if xl command launch qemu with appropriate command arguments.
virtio-pci is just a virtual PCI device.

Takeshi

2011/4/27 Wei Liu <liuw@liuw.name>:
> Hi, all.
>
> I''m Wei Liu, a graduate student from Wuhan University, Hubei,
China.
> I''m accepted to GSoC 2011 for Xen and responsible for the project
> VirtIO on Xen. It''s my honor to get accepted and involved in this
> wonderful community. I''ve been doing Xen development for my lab
since
> late 2009.
>
> As you all know, VirtIO is a generic paravirtualized mainly used in
> KVM now. But it should not be too hard to port VirtIO to Xen. When
> done, Xen will have access to Linux kernel''s VirtIO interfaces and
> developers will have an alternative way to deliver PV drivers besides
> from the original ring buffer flavor. This project requires: Modify
> upstream QEMU, replace KVM-specific interface with generic QEMU
> function; Modify Xen / Xentools to support VirtIO; Modify Linux
> kernel''s VirtIO interfaces.
>
> We must take two usage scenarios into consideration:
>
> 1. PV-on-HVM;
> 2. Normal PV.
>
> These two scenarios require working on different set of functions:
>
> 1. XenBus vs VirtualPCI, it''s about how to create a channel;
> 2. PV vs HVM, it''s about how events are handled.
>
> Most of the code in VirtIO will be left as-it-is. But the notification
> mechanism should be replaced with Xen''s event channel. This
applies to
> QEMU''s porting as well.
>
> In the PV on HVM case, QEMU needs to use event channel to get / send
> notification and foreign mapping / grant table functions in libxc
> /libxl to map memory pages. Virtual PCI bus will be used to establish
> a channel between Dom0 and DomU. In some sense, it makes no
> differences on the Linux kernel side.
>
> In the normal PV case, QEMU needs to use event channel to get / send
> notification, and foreign mapping functions in libxc / libxl to map
> memory pages. XenBus / Xenstore will be used to establish a channel
> between Dom0 and DomU. Linux VirtIO driver should use Xen''s event
> channel as kick / notify function.
>
> When the porting is finished, I will carry on some performance tests
> with standardized tools such as ioperf, netperf and kernbench.
> Testsuites will be run on five different configurations:
>
> 1. Native Linux
> 2. Xen with PV-on-HVM VirtIO support
> 3. Xen with normal PV VirtIO support
> 4. Xen with original PV driver support
> 5. KVM with VirtIO support
>
> A short report will be written based on the results.
>
> This is a brief introduction to the project. Any comments are welcomed.
>
>
> --
> Best regards
> Wei Liu
> Twitter: @iliuw
> Site: http://liuw.name
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
Takeshi HASEGAWA <hasegaw@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi all,

I just confirmed virtio-net-pci is available on xen-unstable + upstream-qemu
(Anthony''s  v14 patch)

You need the combination below:
- latest xen-unstable from hg tree (no patch needed)
- qemu-dm-v14 branch, from git://xenbits.xen.org/people/aperard/qemu-dm.git
- guest OS that support virtio

Procedure:
- vif = [ ''type=ioemu,
bridge=br0,mac=00:16:3e:09:3a:7d,model=virtio'' ]
- xl create /etc/xen/xxxx

Guest OS settings:
-   boot linux with kernel parameter "pci=nomsi" on HVM domain.
  MSI-X is not properly injected to guest for now
  (/proc/interrupts says zero interrupts)

-- 
Takeshi HASEGAWA <hasegaw@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Apr 27, 2011 at 10:05 PM, Takeshi HASEGAWA <hasegaw@gmail.com>
wrote:
> That''s why I am trying to run Fedora 14 on upstream-qemu +
xen-unstable.
>
> On HVM domain, as SPICE worked with some libxl patches, I guess virtio-pci
> should work if xl command launch qemu with appropriate command arguments.
> virtio-pci is just a virtual PCI device.
>
> Takeshi
>
Thanks for your comment.

By the way, SPICE is also planned to be ported. Can you provide links
to those libxl patches? So that I will not need to reinvent the wheel.

-- 
Best regards
Wei Liu
Twitter: @iliuw
Site: http://liuw.name

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

See below.
http://markmail.org/message/vrmk2lixrcc6tpdd


2011/4/28 Wei Liu <liuw@liuw.name>:
> On Wed, Apr 27, 2011 at 10:05 PM, Takeshi HASEGAWA
<hasegaw@gmail.com> wrote:
>> That''s why I am trying to run Fedora 14 on upstream-qemu +
xen-unstable.
>>
>> On HVM domain, as SPICE worked with some libxl patches, I guess
virtio-pci
>> should work if xl command launch qemu with appropriate command
arguments.
>> virtio-pci is just a virtual PCI device.
>>
>> Takeshi
>>
>
> Thanks for your comment.
>
> By the way, SPICE is also planned to be ported. Can you provide links
> to those libxl patches? So that I will not need to reinvent the wheel.
>
> --
> Best regards
> Wei Liu
> Twitter: @iliuw
> Site: http://liuw.name
>


-- 
Takeshi HASEGAWA <hasegaw@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Wei,
welcome to the community. Looking forward to work with you. Stefano 
Stabellini will be Wei''s GSoC mentor.
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel