Re: [Hampshire] Gigabit networking under Xen

Top Page
Author: Hugo Mills
Date:  
To: Hampshire LUG Discussion List
Subject: Re: [Hampshire] Gigabit networking under Xen

Reply to this message
gpg: failed to create temporary file '/var/lib/lurker/.#lk0x571c9100.hantslug.org.uk.1018': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Thu Mar 27 15:20:47 2008 GMT
gpg: using DSA key 20ACB3BE515C238D
gpg: Can't check signature: No public key
On Thu, Mar 27, 2008 at 02:56:30PM +0000, Tony Whitmore wrote:
> On Thu, 27 Mar 2008 13:18:11 +0000, Hugo Mills <hugo@???> wrote:
> > You
> > can speed up the I/O by adding PV drivers. virtio is the Linux
> > "native" PV implementation, and in theory is (or will be) supported by
> > qemu, Xen, VMWare and lguest.
>
> Virtio is pretty new to the kernel, only being in version 2.6.24 AFAICT. In
> the case of a Debian Etch domU I guess I'd be looking for a backported
> kernel if I want the virtio goodness? I assume there are then further
> tweaks to be made inside the domU to get it to use the virtio drivers
> rather than the 8139too or other default drivers.


If you tell the host to present a virtio net device instead of the
RTL-8139 device, then the domU will (if given the right drivers) use
that one.

> Out of interest, do you know if the same applies to Windows domUs? Are
> there equivalents of virtio drivers which make all the I/O nice and fast?


I'm not aware of any available -- even commercially -- at the
moment.

> >> Unless I've misunderstood, surely the problem is
> >> as much which NICs the hypervisor knows how to present to the domUs as
> >> the drivers for the OS inside the domU itself?
> >
> >    To some extent, yes.

> >
> >    If you're talking paravirtual devices, the "NIC" presented by the
> > host container is a very odd beastie, and doesn't really resemble any
> > form of actual hardware. The PV driver then knows how to talk to that
> > device, and the overall design of the device and its corresponding
> > driver is aimed at maximal efficiency in data transfer.

>
> Does that change with HVM? Presumably that emulates a "full" NIC, or is it
> still an odd beastie?


No, the paravirtual device model is unaffected by the type of
virtualisation used. So you could run full emulation (qemu), userspace
virtualisation (kqemu), "assisted" virtualisation (Xen software mode)
or full virtualisation (kvm, Xen HVM), and the virtio interface would
be the same, and use the same driver.

virtio is simply a way of doing a short-cut code path for getting
I/O data into and out of the VM without emulating a full hardware
interface.

[

The differences between the four VM models I give above are,
roughly speaking, as follows:

- full emulation, as used by qemu and bochs, emulates a full hardware
platform, including emulating everything the CPU does. Typically, this
is done by implementing "code morphing" software which effectively
decompiles the guest CPU instructions and recompiles them into host
CPU instructions. This is the same way that Transmeta CPUs work.

- userspace VM, as used by kqemu, does the code-morphing process
described above for kernel-mode code, and runs user-mode code on the
raw hardware. This can be done because all of the "privileged"
instructions that set up the hardware can only be run from kernel
mode.

- "assisted" VM (my term) runs all of the guest on the raw hardware,
but requires the guest kernel to be modified so that it doesn't ever
try to execute the "privileged" instructions, but instead makes an
"upcall" to the host to perform those functions on the emulated
machine instead of the host one.

- full virtualisation, as used by kvm and Xen HVM, executes all of
the guest instructions on the raw hardware, but with the CPU in a
special "VM" mode. This means that when one of the "privileged"
instructions is executed, the CPU bombs out and calls a special
routine. This routine can then inspect the instruction that was
executed, perform the operation requested on the emulated hardware
instead of the host, and return control back to the guest.

The "privileged" instructions I refer to above are mostly to do
with mapping physical to logical memory, although there are probably a
bunch of others that I don't know about.

]

Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
   --- Do not meddle in the affairs of system administrators,  for ---   
                  they are subtle,  and quick to anger.