From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgDdM-0004yx-Ed for qemu-devel@nongnu.org; Sat, 25 May 2013 08:31:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgDdJ-0003i1-JL for qemu-devel@nongnu.org; Sat, 25 May 2013 08:31:40 -0400 Message-ID: <51A0AF24.3020704@suse.de> Date: Sat, 25 May 2013 14:31:32 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1369066884-431-1-git-send-email-peter.maydell@linaro.org> <519A50EE.8040804@redhat.com> <871u8zp34w.fsf@codemonkey.ws> <87y5b7hyuo.fsf@codemonkey.ws> <519FDDBD.7030201@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [libvirt] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Eric Blake Cc: Anthony Liguori , patches@linaro.org, qemu-trivial@nongnu.org, John Rigby , qemu-devel@nongnu.org, Libvirt , Paolo Bonzini Am 25.05.2013 11:18, schrieb Peter Maydell: > On 24 May 2013 22:38, Eric Blake wrote: >> I think knowing the architecture (such as x86 vs. pseries ppc) is used >> by libvirt to know what default devices the board supports (for exampl= e, >> whether usb is present by default). >=20 > ...but this is a per-board question, since (for instance) some > ARM boards have USB and some do not, some have PCI and some > do not, and so on. If we look beyond what we have at the moment, then Anthony has been promoting the idea of having boards potentially be just a config file wiring up QOM devices. I.e., the distro or user would be able to have random boards with a number of devices on them. In that very general case, much like our boards today, the question of can-I-attach-a-certain-device-on-a-bus becomes: Can a solver come up with a path from any device on the board to a device exposing the required bus. E.g., if there is either some USB host interface on SysBus or a PCI host bridge and either a PCI-USB bridge plugged or available to plug, USB devices can be offered - which would then dynamically rule out s390-virtio and s390-ccw-virtio without hardcoding anything in libvirt. Problem is, our devices often have no static way of telling what busses they will/may provide*, so instantiating would often be the only way to find out. * Well, pci-host-bridge as base type might indicate PCIBus to a human, but ISABus, USBBus and other bridges have non-telling base types. >> There's probably still room for >> improvement for communication between libvirt and qemu on what exactly >> is being supported, and knowing an architecture type may be too broad = of >> a knob compared to what is really wanted, except that I don't have a >> good handle on what is really wanted. Knowing the provided architecture would today give us hints what -cpu options may be supported. That becomes moot in a future multi-architecture case though, where devices might be constructed from config or some generic object-create QMP command with qom-set for device options. > It does sound like we could use a more specific enquiry mechanism. Ack, but sadly qemu-system-foo -M bar -S + qom-list + qom-list-types is the most accurate interface I can think of today. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg