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: <4B327CE5.7050705@redhat.com>
Date:	Wed, 23 Dec 2009 22:26:13 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Gregory Haskins <gregory.haskins@...il.com>,
	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 09:27 PM, Andi Kleen wrote:
> Ingo Molnar<mingo@...e.hu>  writes:
>
>    
>> Yes, there's (obviously) compatibility requirements and artifacts and past
>> mistakes (as with any software interface), but you need to admit it to
>>      
> Yes that's exactly what I meant.
>    

And we do make plenty of mistakes.  And when we fix them, we have to 
maintain bug-compatibility to allow live migration from the broken 
version to the good version.  If you're ever feeling overly happy, do 
some compat work in qemu and it will suck a year's worth or two of your 
life force a pop.

>> yourself that your "virtualization is sloppy just like hardware" claim is just
>>      
> In my experience hardware is a lot less sloppy than software.
> Imagine your latest CPU had as many regressions as 2.6.32 @)
>
> I wish software and even VMs were as good.
>
>    

Me too.

>> a cheap excuse to not do a proper job of interface engineering.
>>      
> Past mistakes cannot be easily fixed. And undoubtedly even the new
> shiny interfaces will have bugs and problems. Also the behaviour is
> often not completely understood. Maybe it can be easier debugged with
> fully available source, but even then it's hard to fix the old
> software (or rather even if you can fix it deploy the fixes). In
> that regard it's a lot like hardware.
>
> I agree with you that this makes it important to design good
> interfaces, but again realistically mistakes will be made
> and they cannot be all fixed retroactively.
>    

Our principal tool for this is to avoid introducing new interfaces 
whenever possible.  We try to stick to established hardware standards 
(so we don't need to sloppily define them, and get guest compatibility 
for free).

Hardware (both virt and non-virt) faces the same problems as software 
here.  So as hardware solutions are introduced, we adopt them, and 
usually the virt extensions vendors follow with accelerations for these 
paths as well.

-- 
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/