On Sun, Mar 14, 2010 at 10:26:14AM +0300, Michael Tokarev wrote: > Josh Triplett wrote: > > Package: qemu-kvm > > Version: 0.11.0+dfsg-1 > > Severity: wishlist > > > > 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. > > What do you mean here by 'attempts to access them as "real" > 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.
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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
