Re: [libvirt] [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line
Peter Maydell <peter.maydell@linaro.org> writes:
On 22 May 2013 14:15, Anthony Liguori <aliguori@us.ibm.com> wrote:
Paolo Bonzini <pbonzini@redhat.com> writes:
You don't need to know what targets were supported in the version that you compiled from. Only one target is supported in this executable anyway.
It seems useful to me. One day we may support multiple targets per executable.
Why would you care about which architectures the executable supports? What you actually want to know is which machine models are supported; whether board foo happens to be ARM or PPC isn't really very interesting IMHO.
That's a very good point. It was the libvirt folks that requested this. Perhaps they can shed some light on the logic? Regards, Anthony Liguori
-- PMM
Il 22/05/2013 16:29, Anthony Liguori ha scritto:
Peter Maydell <peter.maydell@linaro.org> writes:
On 22 May 2013 14:15, Anthony Liguori <aliguori@us.ibm.com> wrote:
Paolo Bonzini <pbonzini@redhat.com> writes:
You don't need to know what targets were supported in the version that you compiled from. Only one target is supported in this executable anyway.
It seems useful to me. One day we may support multiple targets per executable.
Why would you care about which architectures the executable supports? What you actually want to know is which machine models are supported; whether board foo happens to be ARM or PPC isn't really very interesting IMHO.
That's a very good point. It was the libvirt folks that requested this. Perhaps they can shed some light on the logic?
There is processor-dependent logic in libvirt, for example the CPUID bits. Paolo
On 05/22/2013 08:29 AM, Anthony Liguori wrote:
Peter Maydell <peter.maydell@linaro.org> writes:
On 22 May 2013 14:15, Anthony Liguori <aliguori@us.ibm.com> wrote:
Paolo Bonzini <pbonzini@redhat.com> writes:
You don't need to know what targets were supported in the version that you compiled from. Only one target is supported in this executable anyway.
It seems useful to me. One day we may support multiple targets per executable.
Why would you care about which architectures the executable supports? What you actually want to know is which machine models are supported; whether board foo happens to be ARM or PPC isn't really very interesting IMHO.
That's a very good point. It was the libvirt folks that requested this. Perhaps they can shed some light on the logic?
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). 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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.
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.
It does sound like we could use a more specific enquiry mechanism. -- PMM
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
participants (5)
-
Andreas Färber -
Anthony Liguori -
Eric Blake -
Paolo Bonzini -
Peter Maydell