tags 561879 + wontfix thanks 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. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
