Currently, kvm defaults to emulated hardware, not virtio.  To make the
use of virtio more automatic, I'd propose that KVM's virtio devices
should have the ability to handle non-virtio systems (by also handling
the attempts to access them as "real" hardware), and then KVM should
default to these virtio devices with fallbacks.

- Josh Triplett

tags 561879 + wontfix
thanks

Josh Triplett wrote:
hardware'?  I'm not sure I follow.

A "real" hardware usually has one or more "buses", and zero
or more devices attached to each bus.  When a system boots
it discovers the available buses and probes devices on each
bus to find out which devices are present.  A system does
not go right to "pci bus, slot #3, device #4" trying to
talk with it as if it were piix ide controller.

I can think of exporting the same device (say, a NIC) in
kvm on two buses simultaneously - both on pci as rtl8139
and on virtio bus as virtio-net, so that both will work.
But this is a way to trouble: it will easily confuse
guest who will think it has in fact 2 NICs, not 1.  The
same is for disk controllers and hard drives attached
to them - multipath is confusing for guests not especially
prepared for that.

Current choice is made based on the maximum compatibility,
the easiest way for almost any guest to "just work".  That
choice is easy to change by actually specifying what kind
of devices one want to expose to guests.  Note that tools
which intend to implement some management for kvm guests
(virt-manager for example) _always_ specify which devices
to emulate, without relying on built-in defaults.

There wont be multipath like above, as it is a way for
trouble as described above.  At least not per default,
which is what you're talking about.

Maybe there's other, 3rd way - like, for example, if
guest probed virtio bus, stop providing devices on
pci bus.  But this is, again, a way to trouble because
guest behavior becomes non-deterministic (depends on
the order in which guest discovers devices, which,
in turn, depends on the module load order and so on).
So it is, again, something that should not be enabled
by default.

So I'm marking this as "wontfix" for now.

Thanks!

/mjt

I certainly would not propose having a device accessible via two
different mechanisms simultaneously.

The solution I had in mind would present the guest with a "real" device,
on a bus, that it can enumerate.  The guest enumerates it, and finds a
device it knows how to talk to as "real" hardware.  It *also* finds some
additional information (for instance, a magic PCI capability) that tells
it that device has virtio support.  If the guest knows about these
dual-mode virtio devices specifically, then it will make an appropriate
call to start talking to the device via virtio, and never talk to the
device as "real" hardware again.  If the guest *doesn't* know about the
dual-mode virtio device, it will talk to the device as "real" hardware,
and it will work.

This could only show up as two different devices if kvm made the device
look exactly like existing virtio devices currently do; I wouldn't
suggest doing that.  Instead, dual-mode virtio devices would appear
primarily as "real" hardware, but with some additional information that
OSes could notice that allows them to explicitly start using the devices
via virtio.

This would work deterministically, could not possibly show up as two
devices, and shouldn't add much additional complexity to either kvm or
virtio-capable guest OSes.

Does that make sense?

- Josh Triplett