Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/27/2009 03:34 PM, Gregory Haskins wrote:
On 12/27/09 4:33 AM, Avi Kivity wrote:
On 12/24/2009 11:36 AM, Gregory Haskins wrote:
As a twist on this, the VMware paravirt driver interface is so
hardware-like that they're getting hardware vendors to supply cards that
implement it.  Try that with a pure software approach.

Any hardware engineer (myself included) will tell you that, generally
speaking, what you can do in hardware you can do in software (think of
what QEMU does today, for instance).  It's purely a cost/performance
tradeoff.

I can at least tell you that is true of vbus.  Anything on the vbus side
would be equally eligible for a hardware implementation, though there is
not reason to do this today since we have equivalent functionality in
baremetal already.
There's a huge difference in the probability of vmware getting cards to
their spec, or x86 vendors improving interrupt delivery to guests,
compared to vbus being implemented in hardware.
Thats not relevant, however.  I said in the original quote that you
snipped that I made it a software design on purpose, and you tried to
somehow paint that as a negative because vmware made theirs
"hardware-like" and you implied it could not be done with my approach
with the statement "try that with a pure software approach".  And the
bottom line is that the statement is incorrect and/or misleading.

It's not incorrect. VMware stuck to the pci specs and as a result they can have hardware implement their virtual NIC protocol. For vbus this is much harder to do since you need a side-channel between different cards to coordinate interrupt delivery. In theory you can do eveything if you don't consider practicalities.

That's a digression, though, I'm not suggesting we'll see virtio hardware or that this is a virtio/pci advantage vs. vbus. It's an anecdote showing that sticking with specs has its advantages.

wrt pci vs vbus, the difference is in the ability to use improvements in interrupt delivery accelerations in virt hardware. If this happens, virtio/pci can immediately take advantage of it, while vbus has to stick with software delivery for backward compatibility, and all that code becomes a useless support burden.

As an example of what hardware can do when it really sets its mind to it, s390 can IPI from vcpu to vcpu without exiting to the host.

The only motiviation is if you wanted to preserve
ABI etc, which is what vmware is presumably after.  However, I am not
advocating this as necessary at this juncture.

Maybe AlacrityVM users don't care about compatibility, but my users do.
Again, not relevant to this thread.  Making your interface
"hardware-like" buys you nothing in the end, as you ultimately need to
load drivers in the guest either way, and any major OS lets you extend
both devices and buses with relative ease.  The only counter example
would be if you truly were "hardware-exactly" like e1000 emulation, but
we already know that this means it is hardware centric and not
"exit-rate aware" and would perform poorly.  Otherwise "compatible" is
purely a point on the time line (for instance, the moment virtio-pci ABI
shipped), not an architectural description such as "hardware-like".

True, not related to the thread. But it is a problem. The difference between virtio and vbus here is that virtio is already deployed and its users expect not to reinstall drivers [1]. Before virtio existed, people could not deploy performance sensitive applications on kvm. Now that it exists, we have to support it without requiring users to touch their guests.

That means that without proof that virtio cannot be scaled, we'll keep supporting and extending it.


[1] Another difference is the requirement for writing a "bus driver" for every supported guest, which means dealing with icky bits like hotplug.

--
error compiling committee.c: too many arguments to function

--
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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux