linux-kernel - 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: <4B327F3A.9020101@redhat.com>
Date:	Wed, 23 Dec 2009 22:36:10 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <gregory.haskins@...il.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/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.

We had the advantage of course of starting with virt extensions, so it 
was a no-brainer: paravirt only where absolutely required.  Where we 
deviated from this, it backfired.

>>   - Gregory claims that the AlacricityVM patches are not a replacement for KVM.
>>     I.e. there's no intention to phase out any 'old stuff'
>>      
> There's no reason to phase anything out, except perhaps the virtio-pci
> transport.  This is one more transport, plugging into virtio underneath
> (just like virtio-pci, virtio-lguest, and virtio-s390).  I am not even
> suggesting that the old transport has to go away, per se.  It is the KVM
> maintainers who insist on it being all or nothing.  For me, I do not see
> the big deal in having one more "model" option in the qemu cmd-line, but
> that is just my opinion.  If the maintainers were really so adamant that
> choice is pure evil, I am not sure why we don't see patches for removing
> everything but one model type in each IO category.  But I digress.
>    

We have to support users (also known as customers in some areas), so we 
have to keep the old stuff.  We have limited resources, so we want to 
maintain as little as possible.  We'll do it if we have to, but I'm 
totally unconvinced we have to.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/