Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

Gregory Haskins
2009-12-24T09:36:30Z

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]