On 12/23/09 4:01 PM, Avi Kivity wrote: > On 12/23/2009 10:36 PM, Avi Kivity wrote: >> On 12/23/2009 06:44 PM, Gregory Haskins wrote: >>> >>>> - Are a pure software concept >>> By design. In fact, I would describe it as "software to software >>> optimized" as opposed to trying to shoehorn into something that was >>> designed as a software-to-hardware interface (and therefore has >>> assumptions about the constraints in that environment that are not >>> applicable in software-only). >>> >> >> And that's the biggest mistake you can make. Look at Xen, for >> instance. The paravirtualized the fork out of everything that moved >> in order to get x86 virt going. And where are they now? x86_64 >> syscalls are slow since they have to trap to the hypervisor and >> (partially) flush the tlb. With npt or ept capable hosts performance >> is better for many workloads on fullvirt. And paravirt doesn't >> support Windows. Their unsung hero Jeremy is still trying to upstream >> dom0 Xen support. And they get to support it forever. >> >> VMware stuck with the hardware defined interfaces. Sure they had to >> implement binary translation to get there, but as a result, they only >> have to support one interface, all guests support it, and they can >> drop it on newer hosts where it doesn't give them anything. > > 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. 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. So sorry, your statement is not relevant. -Greg >
Attachment:
signature.asc
Description: OpenPGP digital signature
