[Qemu-devel] Doubts about Kvm architecture

[Qemu-devel] Doubts about Kvm architecture

[Maurício Almeida]

Hello Guys!
My name is Maurício, we are making a study about Kvm Paravirtualized and
Full virtualized at our University, we are from University Federal of Santa
Maria.

Can you give us some papers about how the Kvm or Qemu executes the I/O Network
with one emulated Device?

We executed some tests using Virtio Driver and e1000 emulated driver, the
network output of Virtio is normal and use four of the four Machine Cpu's,
but the output of e1000 Emulated driver was too low about Virtio and It
only used one of the four machine cpu's during the network test execution.

The Traffic of Virtio was 956 MB/s while e1000 Emulated Driver was 192
MB/s, both using Packet size of 1518 Bytes.

Why when it used e1000 Emulated Driver the traffic was to low and use only
one Cpu all the time?
Do Qemu or Kvm Guest need some specific configuration to use all CPU's?

Do you have any paper where we can find in details if Qemu is limited to
use one CPU when use Network Emulated Driver?

Thank you
Att Maurício Almeida

Re: [Qemu-devel] Doubts about Kvm architecture

[Mihai Donțu]

On Wed, 2017-05-31 at 14:09 -0300, Maurício Almeida wrote:
> My name is Maurício, we are making a study about Kvm Paravirtualized
> and Full virtualized at our University, we are from University Federal
> of Santa Maria.
> Can you give us some papers about how the Kvm or Qemu executes the I/O
> Network with one emulated Device?
> 
> We executed some tests using Virtio Driver and e1000 emulated driver,
> the network output of Virtio is normal and use four of the four
> Machine Cpu's, but the output of e1000 Emulated driver was too low
> about Virtio and It onlyused one of the four machine cpu's during the
> network test execution.
> The Traffic of Virtio was 956 MB/s while e1000 Emulated Driver was 192
> MB/s, both using Packet size of 1518 Bytes.
> 
> Why when it used e1000 Emulated Driver the traffic was to low and use
> only one Cpu all the time?
> Do Qemu or Kvm Guest need some specific configuration to use all CPU's?
> 
> Do you have any paper where we can find in details if Qemu is limited
> to use one CPU when use Network Emulated Driver?

A cursory look over the qemu e1000 driver would suggest that it does
not support multithreading. virtio largely bypasses the qemu hw
machinery.

-- 
Mihai Donțu

Re: [Qemu-devel] Doubts about Kvm architecture

[Eric Blake]

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

On 05/31/2017 11:56 AM, Maurício Almeida wrote:

> The Traffic of Virtio was 956 MB/s while e1000 Emulated Driver was 192
> MB/s, both using Packet size of 1518 Bytes.

The quick answer - yes, that's the expected results, because paravirt is
SOOO much more direct than fully-emulated.  Everything done in the e1000
driver has to emulate what hardware would do, which tends to be a LOT of
register reads and writes to device memory, which in turn implies a LOT
of VMEXITs with corresponding overhead as you are paging between the
guest and host to handle the full sequence.  Meanwhile, the virtio
driver was designed from the ground up to be as efficient as possible,
by intentionally arranging memory layout and handshake protocols so that
there are as few memory-mapped register writes, and therefore as few
VMEXITs, as possible, for better speed and multithreading.

> 
> Why when it used e1000 Emulated Driver the traffic was to low and use only
> one Cpu all the time?

For any modern OS, the e1000 driver should only be used as a crutch to
get the system up and running until you can install and switch over to
the virtio drivers (we have it because it is a driver that is most
likely already installed on a guest OS out-of-the-box, while the virtio
driver might be an extra download or install after the initial guest
install has completed).  So optimizing the e1000 driver to run on
multiple vcpus is not our priority; rather, you should be optimizing
your guest provisioning setup to get switched over to the virtio drivers
as soon as possible.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]