9:29 a.m.
Peter Maydell <peter.maydell(a)linaro.org> writes:
On 22 May 2013 14:15, Anthony Liguori <aliguori(a)us.ibm.com>
wrote:
> Paolo Bonzini <pbonzini(a)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
9:38 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line
Il 22/05/2013 16:29, Anthony Liguori ha scritto:
Peter Maydell <peter.maydell(a)linaro.org> writes:
> On 22 May 2013 14:15, Anthony Liguori <aliguori(a)us.ibm.com> wrote:
>> Paolo Bonzini <pbonzini(a)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
4:38 p.m.
New subject: [libvirt] [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line
On 05/22/2013 08:29 AM, Anthony Liguori wrote:
Peter Maydell <peter.maydell(a)linaro.org> writes:
> On 22 May 2013 14:15, Anthony Liguori <aliguori(a)us.ibm.com> wrote:
>> Paolo Bonzini <pbonzini(a)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
4:18 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line
On 24 May 2013 22:38, Eric Blake <eblake(a)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
7:31 a.m.
New subject: [libvirt] [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line
Am 25.05.2013 11:18, schrieb Peter Maydell:
On 24 May 2013 22:38, Eric Blake <eblake(a)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
4202
days inactive
4205
days old
4 comments
5 participants
participants (5)
-
Andreas Färber -
Anthony Liguori -
Eric Blake -
Paolo Bonzini -
Peter Maydell