Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

[Gregory Haskins]

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.

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



>

Attachment: signature.asc
Description: OpenPGP digital signature