From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=55407 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PnTKm-0001pK-ID
	for qemu-devel@nongnu.org; Thu, 10 Feb 2011 05:01:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PnTKg-0007SN-Dk
	for qemu-devel@nongnu.org; Thu, 10 Feb 2011 05:01:03 -0500
Received: from mail-fx0-f45.google.com ([209.85.161.45]:41447)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PnTKg-0007SB-9M
	for qemu-devel@nongnu.org; Thu, 10 Feb 2011 05:01:02 -0500
Received: by fxm12 with SMTP id 12so1295658fxm.4
	for <qemu-devel@nongnu.org>; Thu, 10 Feb 2011 02:01:01 -0800 (PST)
Message-ID: <4D53B752.1080804@codemonkey.ws>
Date: Thu, 10 Feb 2011 11:00:50 +0100
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] KVM call minutes for Feb 8
References: <m3k4hasb3i.fsf@blackfin.pond.sub.org>
	<4D51B1C9.3080507@codemonkey.ws>
	<m3r5bhhc0d.fsf@blackfin.pond.sub.org>
	<4D526D0D.9020507@codemonkey.ws>
	<m3pqr1s86w.fsf@blackfin.pond.sub.org>
	<4D52A86A.1030407@codemonkey.ws>
	<AANLkTimtswr5fN9PGVnTSxb9szu12bTC0s4tVwbku-J5@mail.gmail.com>
	<4D52F20A.7070009@codemonkey.ws>
	<AANLkTi=JzM21XfDR+YO9JY=e8ONGDWVR6YeYdQ7jzzrk@mail.gmail.com>
	<4D539800.3070802@codemonkey.ws> <20110210090748.GD673@redhat.com>
In-Reply-To: <20110210090748.GD673@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gleb Natapov <gleb@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>, Chris Wright <chrisw@redhat.com>, Markus Armbruster <armbru@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org

On 02/10/2011 10:07 AM, Gleb Natapov wrote:
> So what if it is easier, it doesn't mean it is correct thing to do.

If we spend the next 10 years trying to do the "correct thing" for some 
arbitrary definition of correct, that's not terribly useful.

It's really simple actually.  Let's do the least clever thing and model 
how hardware actual works.  Once we have that, we can try to be better 
than real hardware (if it's possible).

>
>> If all composition is done through a factory interface, it doesn't.
>> But my main argument here is that we shouldn't try to make all
>> composition done through a factory interface--only where it makes
>> sense.
>>
>> So very concretely, I'm suggesting we do the following to target-i386:
>>
>> 1) make the i440fx device have an embedded ide controller, piix3,
>> and usb controller that get initialized automatically.  The piix3
>> embeds the PCI-to-ISA bridge along with all of the default ISA
>> devices (rtc, serial, etc.).
>>      
> This may be a problem even from security point of view. What if usb code
> (ide, serial, parallel) has guest exploitable bug? Currently I can happily
> continue running guests if they do not need affected subsystem. If we'll
> get it your way I will no longer be able to do so.
>    

qemu -device i440fx,ide=off

If you really care to do this.  But this desire to remove devices is 
silly IMHO.  Concerns about security are misplaced.  If you have to 
change the way a guest is invoked in order to eliminate security 
problems, then there's something seriously wrong.

Regards,

Anthony Liguori