Re: [Qemu-devel] [libvirt] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line

["Andreas Färber" <afaerber@suse.de>]

Am 25.05.2013 11:18, schrieb Peter Maydell:
> On 24 May 2013 22:38, Eric Blake <eblake@redhat.com> 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 example,
>> whether usb is present by default).
> 
> ...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

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg