From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz51n-0005CA-Ab for qemu-devel@nongnu.org; Mon, 23 Jun 2014 10:15:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wz51e-0005Gc-V1 for qemu-devel@nongnu.org; Mon, 23 Jun 2014 10:15:23 -0400 Received: from mail-pb0-f42.google.com ([209.85.160.42]:46549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz51e-0005GE-QN for qemu-devel@nongnu.org; Mon, 23 Jun 2014 10:15:14 -0400 Received: by mail-pb0-f42.google.com with SMTP id ma3so5956992pbc.29 for ; Mon, 23 Jun 2014 07:15:13 -0700 (PDT) Message-ID: <53A8366B.1020301@ozlabs.ru> Date: Tue, 24 Jun 2014 00:15:07 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] machines and versions - why so many? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "qemu-devel@nongnu.org" Cc: Paolo Bonzini , Paul Mackerras , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Alexander Graf Hi! I have been hearing recently that we (server PPC) should have more that just one pseries machine in QEMU because this is what everybody else does :) My current understanding is that multiple machines (like pc-i440fx-1.4..2.1, and many others) are needed: 1) for the -nodefaults case when a lot of devices are still created and there is no other way to configure them; in "pseries", only CPU + empty VIO + empty PCI buses are created, everything else can be created explicitly; nothing to tweak; 2) to enable/disable CPUID_EXT_xxx bits (saw in x86); in "pseries", there is a "compat" property on CPU and that seems to be enough; 3) for devices which are created explicitly and for which we want some capabilities be disabled and we do not want to bother about this every time we run QEMU; ok, this one makes some sense for "pseries" to have (and upcoming endianness register on VGA seems to be the case) but it seems that adding a "compat" or "feature" property to the VGA device (and other devices which deal with this kind of compatibility) is still more architecturally correct thing to do, and let libvirt deal with the rest. Since I (almost) always miss the bigger picture, what do I miss now? :) Thanks! -- Alexey