From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTZTd-0000qO-S2 for qemu-devel@nongnu.org; Wed, 31 Oct 2012 10:41:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTZTW-0003tP-03 for qemu-devel@nongnu.org; Wed, 31 Oct 2012 10:41:05 -0400 Received: from mail-da0-f45.google.com ([209.85.210.45]:50675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTZTV-0003sg-Q2 for qemu-devel@nongnu.org; Wed, 31 Oct 2012 10:40:57 -0400 Received: by mail-da0-f45.google.com with SMTP id n15so647129dad.4 for ; Wed, 31 Oct 2012 07:40:56 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <50913870.2090607@redhat.com> Date: Wed, 31 Oct 2012 15:40:48 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <87k3u82f7b.fsf@blackfin.pond.sub.org> <509000E8.9090703@redhat.com> <509008A3.5060908@redhat.com> <87txtbu0jg.fsf@codemonkey.ws> <878vamn3ok.fsf@blackfin.pond.sub.org> <87ehkelo38.fsf@blackfin.pond.sub.org> In-Reply-To: <87ehkelo38.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] On block interface types in general, IF_AHCI in particular List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Stefan Hajnoczi , Jason Baron , qemu-devel@nongnu.org, Alexander Graf , Gerd Hoffmann , Anthony Liguori Il 31/10/2012 15:20, Markus Armbruster ha scritto: > One more thing: on a *major* upgrade, I'd rather deal with immediately > obvious breakage (does not boot) than rotten performance. > > If we make "q35 with compat IDE" the default, we'll have to tell users > many, many times not to use the default :( Well, compat IDE is not on the same league as writethrough for bad performance, and virtio is anyway the better choice (and not available just with a different machine type). If they complain we should send them to virtio just as likely. And perhaps we should send them straight to libvirt and libosinfo. Because in some time we'll probably have the same problem with virtio-scsi vs. virtio-blk (features vs. performance), and externalizing the decision is the only sane thing to do. Paolo