Am 25.05.2013 11:18, schrieb Peter Maydell: > On 24 May 2013 22:38, Eric Blake <eblake@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list