On 08/04/2010 10:57 AM, Paolo Bonzini wrote:
On 08/03/2010 11:34 PM, Anthony Liguori wrote:
Comparing (from personal experience) the complexity of the Windows
drivers for Xen and virtio shows that it's not a bad idea at all.
Not quite sure what you're suggesting, but I could have been clearer.
Instead of having virtio-blk where a virtio disk has a 1-1 mapping to a
PCI device, we probably should have just done virtio-scsi.
If you did virtio-scsi you might have as well ditched virtio-pci
altogether and provide a single PCI device just like Xen does. Just
make your network device also speak SCSI (which is actually in the
spec...), and the same for serial devices.
But now your driver that has to implement its own hot-plug/hot-unplug
mechanism rather than deferring it to the PCI subsystem of the OS
(like Xen), greatly adding to the complication. In fact, a SCSI
controller's firmware has a lot of other communication channels with
the driver besides SCSI commands, and all this would be mapped into
additional complexity on both the host side and the guest side. Yet
another reminder of Xen.
Despite the shortcomings, I think virtio-pci is the best example of
balancing PV-specific aspects (do not make things too complicated) and
"real world" aspects (do not invent new buses and the like).
Making virtio-blk a controller doesn't involve much difficulty. We add
LUN to all requests, and send a configuration interrupt (which we
already have) when a LUN is added or removed. Add some config space for
discovering available LUNs.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
