netdev - Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B33361E.3000605@gmail.com>
Date:	Thu, 24 Dec 2009 04:36:30 -0500
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Andi Kleen <andi@...stfloor.org>, kvm@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

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




> 



Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)