10:29 p.m.
This series allows management code to use object-add on X86CPU subclasses, so it
can use it to probe for CPU model information without re-running QEMU. The main
use case for this is to allow management code to create CPU objects and query
the "feature-words" and "filtered-features" properties on the new
objects, to
find out which features each CPU model needs, and to do the same using the
"host" CPU model to check which features can be enabled in a given host.
There's experimental libvirt code to use the new command at:
https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
The experimental code just create the CPU objects to query for feature
information, but doesn't do anything with that data.
Eduardo Habkost (5):
cpu: Initialize cpu->stopped=true earlier
cpu: Don't try to pause CPUs if they are already stopped
pc: Don't crash on apic_accept_pic_intr() if CPU has no apic_state
target-i386: Make CPU objects user-creatable
target-i386: Report QOM class name for CPU definitions
cpus.c | 13 ++++++++++---
exec.c | 1 +
hw/i386/pc.c | 2 +-
qapi-schema.json | 6 +++++-
target-i386/cpu.c | 7 +++++++
5 files changed, 24 insertions(+), 5 deletions(-)
--
1.9.0
10:29 p.m.
New subject: [libvirt] [RFC 1/5] cpu: Initialize cpu->stopped=true earlier
In case something happens and prevents qemu_init_vcpu() from running
after cpu_exec_init() was already called, this will let the rest of the
VCPU handling code know that the CPU is not running yet.
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
cpus.c | 1 -
exec.c | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpus.c b/cpus.c
index 7bbe153..69b0530 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1184,7 +1184,6 @@ void qemu_init_vcpu(CPUState *cpu)
{
cpu->nr_cores = smp_cores;
cpu->nr_threads = smp_threads;
- cpu->stopped = true;
if (kvm_enabled()) {
qemu_kvm_start_vcpu(cpu);
} else if (tcg_enabled()) {
diff --git a/exec.c b/exec.c
index 91513c6..e91decc 100644
--- a/exec.c
+++ b/exec.c
@@ -485,6 +485,7 @@ void cpu_exec_init(CPUArchState *env)
}
cpu->cpu_index = cpu_index;
cpu->numa_node = 0;
+ cpu->stopped = true;
QTAILQ_INIT(&cpu->breakpoints);
QTAILQ_INIT(&cpu->watchpoints);
#ifndef CONFIG_USER_ONLY
--
1.9.0
2:28 p.m.
New subject: [libvirt] [RFC 1/5] cpu: Initialize cpu->stopped=true earlier
On Wed, 30 Apr 2014 17:29:29 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
In case something happens and prevents qemu_init_vcpu() from running
after cpu_exec_init() was already called, this will let the rest of the
VCPU handling code know that the CPU is not running yet.
perhaps default value
should be set even earlier in qom/cpu.c:cpu_common_initfn()
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
cpus.c | 1 -
exec.c | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpus.c b/cpus.c
index 7bbe153..69b0530 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1184,7 +1184,6 @@ void qemu_init_vcpu(CPUState *cpu)
{
cpu->nr_cores = smp_cores;
cpu->nr_threads = smp_threads;
- cpu->stopped = true;
if (kvm_enabled()) {
qemu_kvm_start_vcpu(cpu);
} else if (tcg_enabled()) {
diff --git a/exec.c b/exec.c
index 91513c6..e91decc 100644
--- a/exec.c
+++ b/exec.c
@@ -485,6 +485,7 @@ void cpu_exec_init(CPUArchState *env)
}
cpu->cpu_index = cpu_index;
cpu->numa_node = 0;
+ cpu->stopped = true;
QTAILQ_INIT(&cpu->breakpoints);
QTAILQ_INIT(&cpu->watchpoints);
#ifndef CONFIG_USER_ONLY
10:29 p.m.
New subject: [libvirt] [RFC 2/5] cpu: Don't try to pause CPUs if they are already stopped
This will make the pause_all_cpus() code not crash in case
qemu_init_vcpu() was not called yet for a CPU (so it doesn't have
cpu->thread set yet).
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
cpus.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/cpus.c b/cpus.c
index 69b0530..ca3862b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1070,6 +1070,14 @@ static int all_vcpus_paused(void)
return 1;
}
+static void cpu_kick_if_running(CPUState *cpu)
+{
+ if (!cpu->stopped) {
+ assert(cpu->thread);
+ qemu_cpu_kick(cpu);
+ }
+}
+
void pause_all_vcpus(void)
{
CPUState *cpu;
@@ -1077,7 +1085,7 @@ void pause_all_vcpus(void)
qemu_clock_enable(QEMU_CLOCK_VIRTUAL, false);
CPU_FOREACH(cpu) {
cpu->stop = true;
- qemu_cpu_kick(cpu);
+ cpu_kick_if_running(cpu);
}
if (qemu_in_vcpu_thread()) {
@@ -1094,7 +1102,7 @@ void pause_all_vcpus(void)
while (!all_vcpus_paused()) {
qemu_cond_wait(&qemu_pause_cond, &qemu_global_mutex);
CPU_FOREACH(cpu) {
- qemu_cpu_kick(cpu);
+ cpu_kick_if_running(cpu);
}
}
}
--
1.9.0
10:29 p.m.
New subject: [libvirt] [RFC 3/5] pc: Don't crash on apic_accept_pic_intr() if CPU has no apic_state
apic_accept_pic_intr() returns -1 if gets NULL as argument. So, instead
of checking if apic_accept_pic_intr() returns non-zero, check for return
value > 0.
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
hw/i386/pc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 14f0d91..c747615 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -197,7 +197,7 @@ static void pic_irq_request(void *opaque, int irq, int level)
if (cpu->apic_state) {
CPU_FOREACH(cs) {
cpu = X86_CPU(cs);
- if (apic_accept_pic_intr(cpu->apic_state)) {
+ if (apic_accept_pic_intr(cpu->apic_state) > 0) {
apic_deliver_pic_intr(cpu->apic_state, level);
}
}
--
1.9.0
10:29 p.m.
New subject: [libvirt] [RFC 4/5] target-i386: Make CPU objects user-creatable
Creating X86CPU objects using object-add will allow management code to
probe for details on each CPU model when using "-machine none", and
without having to restart QEMU.
Note that object-add will _not_ create a running VCPU. It is not CPU
hotplug, which will use device_add instead of object-add. It will just
allow some information about the CPU object to be queried from the CPU
object, without starting an actual VCPU thread.
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
target-i386/cpu.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 8fd1497..2417fc8 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -43,6 +43,7 @@
#include "sysemu/sysemu.h"
#include "hw/qdev-properties.h"
#include "hw/cpu/icc_bus.h"
+#include "qom/object_interfaces.h"
#ifndef CONFIG_USER_ONLY
#include "hw/xen/xen.h"
#include "hw/i386/apic_internal.h"
@@ -2832,6 +2833,10 @@ static const TypeInfo x86_cpu_type_info = {
.abstract = true,
.class_size = sizeof(X86CPUClass),
.class_init = x86_cpu_common_class_init,
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_USER_CREATABLE },
+ { }
+ },
};
static void x86_cpu_register_types(void)
--
1.9.0
10:29 p.m.
New subject: [libvirt] [RFC 5/5] target-i386: Report QOM class name for CPU definitions
The new qom-type attributed will be used to indicate that the object-add
QMP command can be used to create CPU objects. This will let management
code to create multiple CPU objects from different classes and CPU
models and query for their information using QOM properties (like the
"feature-words" properties) in a single QEMU instance, instead of having
to re-run QEMU once for each CPU model.
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
qapi-schema.json | 6 +++++-
target-i386/cpu.c | 2 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 0b00427..7d8bec5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3438,11 +3438,15 @@
# Virtual CPU definition.
#
# @name: the name of the CPU definition
+# @qom-type: the name of the QOM class for the CPU model. The presence
+# of this attribute indicates that CPU objects can be created
+# using object-add.
+# (since: 2.1.0)
#
# Since: 1.2.0
##
{ 'type': 'CpuDefinitionInfo',
- 'data': { 'name': 'str' } }
+ 'data': { 'name': 'str', '*qom-type': 'str' }
}
##
# @query-cpu-definitions:
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 2417fc8..897caa4 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1828,6 +1828,8 @@ CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
def = &builtin_x86_defs[i];
info = g_malloc0(sizeof(*info));
info->name = g_strdup(def->name);
+ info->has_qom_type = true;
+ info->qom_type = x86_cpu_type_name(def->name);
entry = g_malloc0(sizeof(*entry));
entry->value = info;
--
1.9.0
3:45 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Wed, 30 Apr 2014 17:29:28 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
This series allows management code to use object-add on X86CPU
subclasses, so it
Is there any reason why "device-add" couldn't be
used?
can use it to probe for CPU model information without re-running
QEMU. The main
use case for this is to allow management code to create CPU objects and query
the "feature-words" and "filtered-features" properties on the new
objects, to
find out which features each CPU model needs, and to do the same using the
"host" CPU model to check which features can be enabled in a given host.
There's experimental libvirt code to use the new command at:
https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
The experimental code just create the CPU objects to query for feature
information, but doesn't do anything with that data.
Eduardo Habkost (5):
cpu: Initialize cpu->stopped=true earlier
cpu: Don't try to pause CPUs if they are already stopped
pc: Don't crash on apic_accept_pic_intr() if CPU has no apic_state
target-i386: Make CPU objects user-creatable
target-i386: Report QOM class name for CPU definitions
cpus.c | 13 ++++++++++---
exec.c | 1 +
hw/i386/pc.c | 2 +-
qapi-schema.json | 6 +++++-
target-i386/cpu.c | 7 +++++++
5 files changed, 24 insertions(+), 5 deletions(-)
4:43 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
On Wed, 30 Apr 2014 17:29:28 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> This series allows management code to use object-add on X86CPU subclasses, so it
Is there any reason why "device-add" couldn't be used?
It needs to work with "-machine none", device_add requires a bus to
exist, and there is no icc-bus on machine_none.
The first thing I considered was making icc-bus user-creatable. Then I
noticed it wouldn't work because object-add always add objects to
/objects, not inside the qdev hierarchy (that's where device_add looks
for the bus).
So, allowing device_add could be possible, but would require changing
more basic infrastructure: either allowing bus-less devices on
device_add, or allowing device_add to add devices outside the qdev
hierarchy, or allowing object-add to create objects outside /objects.
Simply making CPU objects work with object-add was much simpler and less
intrusive. And it had the interesting side-effect of _not_ doing things
that are not required for CPU model probing (like creating an actual
VCPU thread).
> can use it to probe for CPU model information without re-running QEMU. The main
> use case for this is to allow management code to create CPU objects and query
> the "feature-words" and "filtered-features" properties on the
new objects, to
> find out which features each CPU model needs, and to do the same using the
> "host" CPU model to check which features can be enabled in a given host.
>
> There's experimental libvirt code to use the new command at:
> https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
> The experimental code just create the CPU objects to query for feature
> information, but doesn't do anything with that data.
>
> Eduardo Habkost (5):
> cpu: Initialize cpu->stopped=true earlier
> cpu: Don't try to pause CPUs if they are already stopped
> pc: Don't crash on apic_accept_pic_intr() if CPU has no apic_state
> target-i386: Make CPU objects user-creatable
> target-i386: Report QOM class name for CPU definitions
>
> cpus.c | 13 ++++++++++---
> exec.c | 1 +
> hw/i386/pc.c | 2 +-
> qapi-schema.json | 6 +++++-
> target-i386/cpu.c | 7 +++++++
> 5 files changed, 24 insertions(+), 5 deletions(-)
>
--
Eduardo
4:54 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
Il 02/05/2014 16:43, Eduardo Habkost ha scritto:
The first thing I considered was making icc-bus user-creatable. Then
I
noticed it wouldn't work because object-add always add objects to
/objects, not inside the qdev hierarchy (that's where device_add looks
for the bus).
So, allowing device_add could be possible, but would require changing
more basic infrastructure: either allowing bus-less devices on
device_add, or allowing device_add to add devices outside the qdev
hierarchy, or allowing object-add to create objects outside /objects.
Simply making CPU objects work with object-add was much simpler and less
intrusive. And it had the interesting side-effect of _not_ doing things
that are not required for CPU model probing (like creating an actual
VCPU thread).
I like this series in general. I have only some doubts about making the
code somewhat future-proof, hence the three questions I have are really
variations of this same doubt:
* is it worthwhile to extend this to other devices, for management to
query default values of the properties?
* how does this interact with future QOMification of device hotplug
where devices will be hotplugged with object-add? Should
Device::UserCreatable::complete set realized to true in this case in the
future? How will Device::UserCreatable::complete distinguish the two cases?
* Related to this, if Device::UserCreatable::complete will set realized
to true, how will we handle hotplug of interconnected devices where
device 1 needs a link to device 2 and device 2 needs a link to device 1?
Paolo
6:43 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Fri, May 02, 2014 at 04:54:00PM +0200, Paolo Bonzini wrote:
Il 02/05/2014 16:43, Eduardo Habkost ha scritto:
>The first thing I considered was making icc-bus user-creatable. Then I
>noticed it wouldn't work because object-add always add objects to
>/objects, not inside the qdev hierarchy (that's where device_add looks
>for the bus).
>
>So, allowing device_add could be possible, but would require changing
>more basic infrastructure: either allowing bus-less devices on
>device_add, or allowing device_add to add devices outside the qdev
>hierarchy, or allowing object-add to create objects outside /objects.
>
>Simply making CPU objects work with object-add was much simpler and less
>intrusive. And it had the interesting side-effect of _not_ doing things
>that are not required for CPU model probing (like creating an actual
>VCPU thread).
I like this series in general. I have only some doubts about making
the code somewhat future-proof, hence the three questions I have are
really variations of this same doubt:
* is it worthwhile to extend this to other devices, for management
to query default values of the properties?
Well, it was extended automatically to all devices for a few days on
qemu.git, before TYPE_USER_CREATABLE was introduced. In practice many
devices don't like being created without a bus, and/or outside the usual
qdev hierarchy, and/or without getting realized=true set, so bad things
could happen. Isn't that the reason TYPE_USER_CREATABLE was created?
About default values of properties: if all you need is the default value
of properties, that data is already present at class_init-time. We could
allow class introspection to return that data without creating the
objects. It would make sense to me, but I am not sure this would get
accepted. See: http://marc.info/?l=qemu-devel&m=139170587709459
In the case of X86CPUs, all attempts to make the data introspectable at
compile-time or class_init-time (without requiring CPU instances to be
created) didn't work or were rejected in favour of calculating CPUID
data at runtime. We are still slowly changing the X86CPU code in a way
that would make that data instrospectable without creating the actual
objects, but it may take a very long time, and we may never reach that
goal.
* how does this interact with future QOMification of device hotplug
where devices will be hotplugged with object-add? Should
Device::UserCreatable::complete set realized to true in this case in
the future? How will Device::UserCreatable::complete distinguish
the two cases?
I don't know the answer to that. In my specific use case, I don't care
if realized=true is set automatically in the future, as long as QEMU
doesn't crash.
At least in the case of x86 CPUs, it makes sense to set realized=true
only after the CPU is connected to an icc-bus. So, I believe it makes
sense to set realized=true only if/when the object is connected/linked
to a bus/device that triggers realization, or explicitly using qom-set.
* Related to this, if Device::UserCreatable::complete will set
realized to true, how will we handle hotplug of interconnected
devices where device 1 needs a link to device 2 and device 2 needs a
link to device 1?
How do we handle hotplug of interconnected devices today?
--
Eduardo
9:22 a.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Fri, 2 May 2014 11:43:05 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> On Wed, 30 Apr 2014 17:29:28 -0300
> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>
> > This series allows management code to use object-add on X86CPU subclasses, so
it
> Is there any reason why "device-add" couldn't be used?
It needs to work with "-machine none", device_add requires a bus to
exist, and there is no icc-bus on machine_none.
The thing is that CPUID is a
function of machine so using
"-machine none" will provide only approximately accurate data.
I'm not sure that retrieved possibly not accurate data are useful
for libvirt.
The first thing I considered was making icc-bus user-creatable. Then I
noticed it wouldn't work because object-add always add objects to
/objects, not inside the qdev hierarchy (that's where device_add looks
for the bus).
So, allowing device_add could be possible, but would require changing
more basic infrastructure: either allowing bus-less devices on
device_add, or allowing device_add to add devices outside the qdev
hierarchy, or allowing object-add to create objects outside /objects.
Simply making CPU objects work with object-add was much simpler and less
intrusive. And it had the interesting side-effect of _not_ doing things
that are not required for CPU model probing (like creating an actual
VCPU thread).
>
>
> > can use it to probe for CPU model information without re-running QEMU. The
main
> > use case for this is to allow management code to create CPU objects and query
> > the "feature-words" and "filtered-features" properties on
the new objects, to
> > find out which features each CPU model needs, and to do the same using the
> > "host" CPU model to check which features can be enabled in a given
host.
> >
> > There's experimental libvirt code to use the new command at:
> > https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
> > The experimental code just create the CPU objects to query for feature
> > information, but doesn't do anything with that data.
> >
> > Eduardo Habkost (5):
> > cpu: Initialize cpu->stopped=true earlier
> > cpu: Don't try to pause CPUs if they are already stopped
> > pc: Don't crash on apic_accept_pic_intr() if CPU has no apic_state
> > target-i386: Make CPU objects user-creatable
> > target-i386: Report QOM class name for CPU definitions
> >
> > cpus.c | 13 ++++++++++---
> > exec.c | 1 +
> > hw/i386/pc.c | 2 +-
> > qapi-schema.json | 6 +++++-
> > target-i386/cpu.c | 7 +++++++
> > 5 files changed, 24 insertions(+), 5 deletions(-)
> >
>
4:42 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
On Fri, 2 May 2014 11:43:05 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> > On Wed, 30 Apr 2014 17:29:28 -0300
> > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> >
> > > This series allows management code to use object-add on X86CPU subclasses,
so it
> > Is there any reason why "device-add" couldn't be used?
>
> It needs to work with "-machine none", device_add requires a bus to
> exist, and there is no icc-bus on machine_none.
The thing is that CPUID is a function of machine so using
"-machine none" will provide only approximately accurate data.
I'm not sure that retrieved possibly not accurate data are useful
for libvirt.
"-cpu host" doesn't depend on machine, and is the most important thing
right now (because libvirt's checks for host QEMU/kernel/CPU
capabilities is completely broken).
About machine-type data: currently libvirt has no concept of
per-machine-type CPU model data, anyway. We (and libvirt) will need to
address this eventually, but considering our track record, I bet the
QEMU community will take a few years to finally provide that info to
libvirt.
In the meantime, we have a partial solution that fits the current
libvirt data model and is better than the current state (where libvirt
has to duplicate the CPU model data).
Maybe they will use this only for "host", maybe they will use this for
all the other CPU models, we are just providing the mechanism, it's
their decision to use it or not.
>
> The first thing I considered was making icc-bus user-creatable. Then I
> noticed it wouldn't work because object-add always add objects to
> /objects, not inside the qdev hierarchy (that's where device_add looks
> for the bus).
>
> So, allowing device_add could be possible, but would require changing
> more basic infrastructure: either allowing bus-less devices on
> device_add, or allowing device_add to add devices outside the qdev
> hierarchy, or allowing object-add to create objects outside /objects.
>
> Simply making CPU objects work with object-add was much simpler and less
> intrusive. And it had the interesting side-effect of _not_ doing things
> that are not required for CPU model probing (like creating an actual
> VCPU thread).
>
> >
> >
> > > can use it to probe for CPU model information without re-running QEMU. The
main
> > > use case for this is to allow management code to create CPU objects and
query
> > > the "feature-words" and "filtered-features" properties
on the new objects, to
> > > find out which features each CPU model needs, and to do the same using
the
> > > "host" CPU model to check which features can be enabled in a
given host.
> > >
> > > There's experimental libvirt code to use the new command at:
> > > https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
> > > The experimental code just create the CPU objects to query for feature
> > > information, but doesn't do anything with that data.
> > >
> > > Eduardo Habkost (5):
> > > cpu: Initialize cpu->stopped=true earlier
> > > cpu: Don't try to pause CPUs if they are already stopped
> > > pc: Don't crash on apic_accept_pic_intr() if CPU has no apic_state
> > > target-i386: Make CPU objects user-creatable
> > > target-i386: Report QOM class name for CPU definitions
> > >
> > > cpus.c | 13 ++++++++++---
> > > exec.c | 1 +
> > > hw/i386/pc.c | 2 +-
> > > qapi-schema.json | 6 +++++-
> > > target-i386/cpu.c | 7 +++++++
> > > 5 files changed, 24 insertions(+), 5 deletions(-)
> > >
> >
>
--
Eduardo
10:01 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Tue, 6 May 2014 11:42:56 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
> On Fri, 2 May 2014 11:43:05 -0300
> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>
> > On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> > > On Wed, 30 Apr 2014 17:29:28 -0300
> > > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > >
> > > > This series allows management code to use object-add on X86CPU
subclasses, so it
> > > Is there any reason why "device-add" couldn't be used?
> >
> > It needs to work with "-machine none", device_add requires a bus to
> > exist, and there is no icc-bus on machine_none.
> The thing is that CPUID is a function of machine so using
> "-machine none" will provide only approximately accurate data.
> I'm not sure that retrieved possibly not accurate data are useful
> for libvirt.
"-cpu host" doesn't depend on machine, and is the most important thing
right now (because libvirt's checks for host QEMU/kernel/CPU
capabilities is completely broken).
true, but device-add/-cpu host could be used
right now to get the
same CPUID data wile using any machine type or default one without
any of this patches.
About machine-type data: currently libvirt has no concept of
per-machine-type CPU model data, anyway. We (and libvirt) will need to
address this eventually, but considering our track record, I bet the
QEMU community will take a few years to finally provide that info to
libvirt.
I don't think QEMU is issue here, libvirt can use device-add to
probe accurate CPUID on all CPU models on a given machine type now.
libvirt should be fixed to care about machine type and use it to get
correct CPUID data that QEMU provides.
In the meantime, we have a partial solution that fits the current
libvirt data model and is better than the current state (where libvirt
has to duplicate the CPU model data).
Replacing one set of inaccurate CPUIDs with
another is hardly solution.
Maybe they will use this only for "host", maybe they will use this for
all the other CPU models, we are just providing the mechanism, it's
their decision to use it or not.
As I've said above libvirt could use
device-add xxx-host or -cpu host
to get it and second point I object to is providing yet another way
to produce inaccurate CPUID info (libvirt has one already) and to do
so hack [patches 1-3] CPU infrastructure to run out of context it's
supposed to run in. While current API already allows to get correct
CPUID data.
IMHO, libvirt side should take advantage of information QEMU already
provides.
>
> >
> > The first thing I considered was making icc-bus user-creatable. Then I
> > noticed it wouldn't work because object-add always add objects to
> > /objects, not inside the qdev hierarchy (that's where device_add looks
> > for the bus).
> >
> > So, allowing device_add could be possible, but would require changing
> > more basic infrastructure: either allowing bus-less devices on
> > device_add, or allowing device_add to add devices outside the qdev
> > hierarchy, or allowing object-add to create objects outside /objects.
> >
> > Simply making CPU objects work with object-add was much simpler and less
> > intrusive. And it had the interesting side-effect of _not_ doing things
> > that are not required for CPU model probing (like creating an actual
> > VCPU thread).
> >
> > >
> > >
> > > > can use it to probe for CPU model information without re-running
QEMU. The main
> > > > use case for this is to allow management code to create CPU objects
and query
> > > > the "feature-words" and "filtered-features"
properties on the new objects, to
> > > > find out which features each CPU model needs, and to do the same
using the
> > > > "host" CPU model to check which features can be enabled in
a given host.
> > > >
> > > > There's experimental libvirt code to use the new command at:
> > > >
https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
> > > > The experimental code just create the CPU objects to query for
feature
> > > > information, but doesn't do anything with that data.
> > > >
> > > > Eduardo Habkost (5):
> > > > cpu: Initialize cpu->stopped=true earlier
> > > > cpu: Don't try to pause CPUs if they are already stopped
> > > > pc: Don't crash on apic_accept_pic_intr() if CPU has no
apic_state
> > > > target-i386: Make CPU objects user-creatable
> > > > target-i386: Report QOM class name for CPU definitions
> > > >
> > > > cpus.c | 13 ++++++++++---
> > > > exec.c | 1 +
> > > > hw/i386/pc.c | 2 +-
> > > > qapi-schema.json | 6 +++++-
> > > > target-i386/cpu.c | 7 +++++++
> > > > 5 files changed, 24 insertions(+), 5 deletions(-)
> > > >
> > >
> >
>
--
Eduardo
--
Regards,
Igor
10:19 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
On Tue, 6 May 2014 11:42:56 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
> > On Fri, 2 May 2014 11:43:05 -0300
> > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> >
> > > On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> > > > On Wed, 30 Apr 2014 17:29:28 -0300
> > > > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > >
> > > > > This series allows management code to use object-add on X86CPU
subclasses, so it
> > > > Is there any reason why "device-add" couldn't be used?
> > >
> > > It needs to work with "-machine none", device_add requires a bus
to
> > > exist, and there is no icc-bus on machine_none.
> > The thing is that CPUID is a function of machine so using
> > "-machine none" will provide only approximately accurate data.
> > I'm not sure that retrieved possibly not accurate data are useful
> > for libvirt.
>
> "-cpu host" doesn't depend on machine, and is the most important
thing
> right now (because libvirt's checks for host QEMU/kernel/CPU
> capabilities is completely broken).
true, but device-add/-cpu host could be used right now to get the
same CPUID data wile using any machine type or default one without
any of this patches.
device_add can't be used with "-machine none".
>
> About machine-type data: currently libvirt has no concept of
> per-machine-type CPU model data, anyway. We (and libvirt) will need to
> address this eventually, but considering our track record, I bet the
> QEMU community will take a few years to finally provide that info to
> libvirt.
I don't think QEMU is issue here, libvirt can use device-add to
probe accurate CPUID on all CPU models on a given machine type now.
libvirt should be fixed to care about machine type and use it to get
correct CPUID data that QEMU provides.
True, it should. But we still need a solution for the "-cpu host" problem.
>
> In the meantime, we have a partial solution that fits the current
> libvirt data model and is better than the current state (where libvirt
> has to duplicate the CPU model data).
Replacing one set of inaccurate CPUIDs with another is hardly solution.
We could continue arguing about this, but let's ignore the issue about
probing for CPU model information by now, and let's focus on host
capability probing ("-cpu host"), then.
How do you propose fixing that in a reasonable time (in QEMU 2.1)
without requiring libvirt to re-run QEMU?
>
> Maybe they will use this only for "host", maybe they will use this for
> all the other CPU models, we are just providing the mechanism, it's
> their decision to use it or not.
As I've said above libvirt could use device-add xxx-host or -cpu host
to get it and second point I object to is providing yet another way
to produce inaccurate CPUID info (libvirt has one already) and to do
so hack [patches 1-3] CPU infrastructure to run out of context it's
supposed to run in. While current API already allows to get correct
CPUID data.
IMHO, libvirt side should take advantage of information QEMU already
provides.
Current API requires re-running QEMU to query the information. This
series allows it to be run with the "-machine none" QEMU instance that
is already run by libvirt.
>
>
> >
> > >
> > > The first thing I considered was making icc-bus user-creatable. Then I
> > > noticed it wouldn't work because object-add always add objects to
> > > /objects, not inside the qdev hierarchy (that's where device_add
looks
> > > for the bus).
> > >
> > > So, allowing device_add could be possible, but would require changing
> > > more basic infrastructure: either allowing bus-less devices on
> > > device_add, or allowing device_add to add devices outside the qdev
> > > hierarchy, or allowing object-add to create objects outside /objects.
> > >
> > > Simply making CPU objects work with object-add was much simpler and less
> > > intrusive. And it had the interesting side-effect of _not_ doing things
> > > that are not required for CPU model probing (like creating an actual
> > > VCPU thread).
> > >
> > > >
> > > >
> > > > > can use it to probe for CPU model information without re-running
QEMU. The main
> > > > > use case for this is to allow management code to create CPU
objects and query
> > > > > the "feature-words" and "filtered-features"
properties on the new objects, to
> > > > > find out which features each CPU model needs, and to do the same
using the
> > > > > "host" CPU model to check which features can be
enabled in a given host.
> > > > >
> > > > > There's experimental libvirt code to use the new command
at:
> > > > >
https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
> > > > > The experimental code just create the CPU objects to query for
feature
> > > > > information, but doesn't do anything with that data.
> > > > >
> > > > > Eduardo Habkost (5):
> > > > > cpu: Initialize cpu->stopped=true earlier
> > > > > cpu: Don't try to pause CPUs if they are already stopped
> > > > > pc: Don't crash on apic_accept_pic_intr() if CPU has no
apic_state
> > > > > target-i386: Make CPU objects user-creatable
> > > > > target-i386: Report QOM class name for CPU definitions
> > > > >
> > > > > cpus.c | 13 ++++++++++---
> > > > > exec.c | 1 +
> > > > > hw/i386/pc.c | 2 +-
> > > > > qapi-schema.json | 6 +++++-
> > > > > target-i386/cpu.c | 7 +++++++
> > > > > 5 files changed, 24 insertions(+), 5 deletions(-)
> > > > >
> > > >
> > >
> >
>
> --
> Eduardo
>
--
Regards,
Igor
--
Eduardo
10:29 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
Am 06.05.2014 22:19, schrieb Eduardo Habkost:
On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> On Tue, 6 May 2014 11:42:56 -0300
> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
>>> On Fri, 2 May 2014 11:43:05 -0300
>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
>>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>>>> This series allows management code to use object-add on X86CPU
subclasses, so it
>>>>> Is there any reason why "device-add" couldn't be used?
>>>> It needs to work with "-machine none", device_add requires a
bus to
>>>> exist, and there is no icc-bus on machine_none.
>>> The thing is that CPUID is a function of machine so using
>>> "-machine none" will provide only approximately accurate data.
>>> I'm not sure that retrieved possibly not accurate data are useful
>>> for libvirt.
>> "-cpu host" doesn't depend on machine, and is the most important
thing
>> right now (because libvirt's checks for host QEMU/kernel/CPU
>> capabilities is completely broken).
> true, but device-add/-cpu host could be used right now to get the
> same CPUID data wile using any machine type or default one without
> any of this patches.
device_add can't be used with "-machine none".
I see no reason why we couldn't *make* CPUs work on -machine none. The
ICC bus and bridge were a hack to make APIC(?) hot-add work in face of
SysBus; if that prohibits other valid uses now, then evaluating Igor's
memory work for CPU might be an option.
I'm not aware of any real X86CPU dependency on ICCBus, so we might as
well make -device place it on SysBus if no ICCBus is available...
probably much more invasive and potentially dangerous though.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
8:29 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Tue, May 06, 2014 at 10:29:24PM +0200, Andreas Färber wrote:
Am 06.05.2014 22:19, schrieb Eduardo Habkost:
> On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
>> On Tue, 6 May 2014 11:42:56 -0300
>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
>>>> On Fri, 2 May 2014 11:43:05 -0300
>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
>>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
>>>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>>>>> This series allows management code to use object-add on
X86CPU subclasses, so it
>>>>>> Is there any reason why "device-add" couldn't be
used?
>>>>> It needs to work with "-machine none", device_add requires
a bus to
>>>>> exist, and there is no icc-bus on machine_none.
>>>> The thing is that CPUID is a function of machine so using
>>>> "-machine none" will provide only approximately accurate
data.
>>>> I'm not sure that retrieved possibly not accurate data are useful
>>>> for libvirt.
>>> "-cpu host" doesn't depend on machine, and is the most
important thing
>>> right now (because libvirt's checks for host QEMU/kernel/CPU
>>> capabilities is completely broken).
>> true, but device-add/-cpu host could be used right now to get the
>> same CPUID data wile using any machine type or default one without
>> any of this patches.
>
> device_add can't be used with "-machine none".
I see no reason why we couldn't *make* CPUs work on -machine none. The
ICC bus and bridge were a hack to make APIC(?) hot-add work in face of
SysBus; if that prohibits other valid uses now, then evaluating Igor's
memory work for CPU might be an option.
I'm not aware of any real X86CPU dependency on ICCBus, so we might as
well make -device place it on SysBus if no ICCBus is available...
probably much more invasive and potentially dangerous though.
Doing that may be an option, too. But isn't the X86CPU bus type and
object hierarchy part of the API?
Anyway, I thought we were moving away from QDEV, and trying to use a
purely QOM-based model where possible. So I don't see why making
object-add working with X86CPU would be a bad thing, considering that
the alternative requires redoing the X86CPU bus/device hierarchy again,
just to work around device_add limitations.
My other worry is if X86CPU/icc-bus hierarchy rework would be done in
time for 2.1 (and not delay other work). The lack of proper host
capability probing in the libvirt+QEMU stack is a bug, not just a nice
new feature.
--
Eduardo
2:35 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Tue, 06 May 2014 22:29:24 +0200
Andreas Färber <afaerber(a)suse.de> wrote:
Am 06.05.2014 22:19, schrieb Eduardo Habkost:
> On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
>> On Tue, 6 May 2014 11:42:56 -0300
>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
>>>> On Fri, 2 May 2014 11:43:05 -0300
>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
>>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
>>>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>>>>> This series allows management code to use object-add on
X86CPU subclasses, so it
>>>>>> Is there any reason why "device-add" couldn't be
used?
>>>>> It needs to work with "-machine none", device_add requires
a bus to
>>>>> exist, and there is no icc-bus on machine_none.
>>>> The thing is that CPUID is a function of machine so using
>>>> "-machine none" will provide only approximately accurate
data.
>>>> I'm not sure that retrieved possibly not accurate data are useful
>>>> for libvirt.
>>> "-cpu host" doesn't depend on machine, and is the most
important thing
>>> right now (because libvirt's checks for host QEMU/kernel/CPU
>>> capabilities is completely broken).
>> true, but device-add/-cpu host could be used right now to get the
>> same CPUID data wile using any machine type or default one without
>> any of this patches.
>
> device_add can't be used with "-machine none".
I see no reason why we couldn't *make* CPUs work on -machine none. The
ICC bus and bridge were a hack to make APIC(?) hot-add work in face of
SysBus; if that prohibits other valid uses now, then evaluating Igor's
memory work for CPU might be an option.
Yep, if CPU is hot-plugged as bus-less
device.
There is a little concern of APIC device if we go that direction since
in addition to hotpluggable BUS, BUS provides address-space for APIC MMIO.
With that resolved, x86-cpu shouldn't depend on any bus and if there isn't
any current user that uses QOM path to CPU for introspecting (Eduardo's
ABI concern), then it could be done in time for 2.1.
PS:
As side effect cpu/apic will disappear from "info qtree" HMP command output.
I'm not aware of any real X86CPU dependency on ICCBus, so we might as
well make -device place it on SysBus if no ICCBus is available...
probably much more invasive and potentially dangerous though.
Regards,
Andreas
3:07 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Thu, May 15, 2014 at 02:35:01PM +0200, Igor Mammedov wrote:
On Tue, 06 May 2014 22:29:24 +0200
Andreas Färber <afaerber(a)suse.de> wrote:
> Am 06.05.2014 22:19, schrieb Eduardo Habkost:
> > On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> >> On Tue, 6 May 2014 11:42:56 -0300
> >> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> >>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
> >>>> On Fri, 2 May 2014 11:43:05 -0300
> >>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> >>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> >>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
> >>>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> >>>>>>> This series allows management code to use object-add on
X86CPU subclasses, so it
> >>>>>> Is there any reason why "device-add" couldn't
be used?
> >>>>> It needs to work with "-machine none", device_add
requires a bus to
> >>>>> exist, and there is no icc-bus on machine_none.
> >>>> The thing is that CPUID is a function of machine so using
> >>>> "-machine none" will provide only approximately accurate
data.
> >>>> I'm not sure that retrieved possibly not accurate data are
useful
> >>>> for libvirt.
> >>> "-cpu host" doesn't depend on machine, and is the most
important thing
> >>> right now (because libvirt's checks for host QEMU/kernel/CPU
> >>> capabilities is completely broken).
> >> true, but device-add/-cpu host could be used right now to get the
> >> same CPUID data wile using any machine type or default one without
> >> any of this patches.
> >
> > device_add can't be used with "-machine none".
>
> I see no reason why we couldn't *make* CPUs work on -machine none. The
> ICC bus and bridge were a hack to make APIC(?) hot-add work in face of
> SysBus; if that prohibits other valid uses now, then evaluating Igor's
> memory work for CPU might be an option.
Yep, if CPU is hot-plugged as bus-less device.
There is a little concern of APIC device if we go that direction since
in addition to hotpluggable BUS, BUS provides address-space for APIC MMIO.
With that resolved, x86-cpu shouldn't depend on any bus and if there isn't
any current user that uses QOM path to CPU for introspecting (Eduardo's
ABI concern), then it could be done in time for 2.1.
Maybe there are no users of the current QOM path, but we do need a
stable path to allow management to locate the CPU objects. Do we have
one, already?
--
Eduardo
3:09 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
Am 15.05.2014 15:07, schrieb Eduardo Habkost:
On Thu, May 15, 2014 at 02:35:01PM +0200, Igor Mammedov wrote:
> On Tue, 06 May 2014 22:29:24 +0200
> Andreas Färber <afaerber(a)suse.de> wrote:
>
>> Am 06.05.2014 22:19, schrieb Eduardo Habkost:
>>> On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
>>>> On Tue, 6 May 2014 11:42:56 -0300
>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
>>>>>> On Fri, 2 May 2014 11:43:05 -0300
>>>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov
wrote:
>>>>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
>>>>>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>>>>>>>>> This series allows management code to use object-add
on X86CPU subclasses, so it
>>>>>>>> Is there any reason why "device-add"
couldn't be used?
>>>>>>> It needs to work with "-machine none", device_add
requires a bus to
>>>>>>> exist, and there is no icc-bus on machine_none.
>>>>>> The thing is that CPUID is a function of machine so using
>>>>>> "-machine none" will provide only approximately
accurate data.
>>>>>> I'm not sure that retrieved possibly not accurate data are
useful
>>>>>> for libvirt.
>>>>> "-cpu host" doesn't depend on machine, and is the most
important thing
>>>>> right now (because libvirt's checks for host QEMU/kernel/CPU
>>>>> capabilities is completely broken).
>>>> true, but device-add/-cpu host could be used right now to get the
>>>> same CPUID data wile using any machine type or default one without
>>>> any of this patches.
>>>
>>> device_add can't be used with "-machine none".
>>
>> I see no reason why we couldn't *make* CPUs work on -machine none. The
>> ICC bus and bridge were a hack to make APIC(?) hot-add work in face of
>> SysBus; if that prohibits other valid uses now, then evaluating Igor's
>> memory work for CPU might be an option.
> Yep, if CPU is hot-plugged as bus-less device.
> There is a little concern of APIC device if we go that direction since
> in addition to hotpluggable BUS, BUS provides address-space for APIC MMIO.
> With that resolved, x86-cpu shouldn't depend on any bus and if there isn't
> any current user that uses QOM path to CPU for introspecting (Eduardo's
> ABI concern), then it could be done in time for 2.1.
Maybe there are no users of the current QOM path, but we do need a
stable path to allow management to locate the CPU objects. Do we have
one, already?
No, we don't. That question is intertwined with topology modeling. :/
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
3:48 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Thu, 15 May 2014 10:07:51 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
On Thu, May 15, 2014 at 02:35:01PM +0200, Igor Mammedov wrote:
> On Tue, 06 May 2014 22:29:24 +0200
> Andreas Färber <afaerber(a)suse.de> wrote:
>
> > Am 06.05.2014 22:19, schrieb Eduardo Habkost:
> > > On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> > >> On Tue, 6 May 2014 11:42:56 -0300
> > >> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > >>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
> > >>>> On Fri, 2 May 2014 11:43:05 -0300
> > >>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > >>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov
wrote:
> > >>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
> > >>>>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > >>>>>>> This series allows management code to use
object-add on X86CPU subclasses, so it
> > >>>>>> Is there any reason why "device-add"
couldn't be used?
> > >>>>> It needs to work with "-machine none",
device_add requires a bus to
> > >>>>> exist, and there is no icc-bus on machine_none.
> > >>>> The thing is that CPUID is a function of machine so using
> > >>>> "-machine none" will provide only approximately
accurate data.
> > >>>> I'm not sure that retrieved possibly not accurate data are
useful
> > >>>> for libvirt.
> > >>> "-cpu host" doesn't depend on machine, and is the
most important thing
> > >>> right now (because libvirt's checks for host QEMU/kernel/CPU
> > >>> capabilities is completely broken).
> > >> true, but device-add/-cpu host could be used right now to get the
> > >> same CPUID data wile using any machine type or default one without
> > >> any of this patches.
> > >
> > > device_add can't be used with "-machine none".
> >
> > I see no reason why we couldn't *make* CPUs work on -machine none. The
> > ICC bus and bridge were a hack to make APIC(?) hot-add work in face of
> > SysBus; if that prohibits other valid uses now, then evaluating Igor's
> > memory work for CPU might be an option.
> Yep, if CPU is hot-plugged as bus-less device.
> There is a little concern of APIC device if we go that direction since
> in addition to hotpluggable BUS, BUS provides address-space for APIC MMIO.
> With that resolved, x86-cpu shouldn't depend on any bus and if there isn't
> any current user that uses QOM path to CPU for introspecting (Eduardo's
> ABI concern), then it could be done in time for 2.1.
Maybe there are no users of the current QOM path, but we do need a
stable path to allow management to locate the CPU objects. Do we have
one, already?
Can't we add query-cpus QMP command or something like this to hide path
from user.
4:03 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Thu, May 15, 2014 at 03:48:16PM +0200, Igor Mammedov wrote:
On Thu, 15 May 2014 10:07:51 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> On Thu, May 15, 2014 at 02:35:01PM +0200, Igor Mammedov wrote:
> > On Tue, 06 May 2014 22:29:24 +0200
> > Andreas Färber <afaerber(a)suse.de> wrote:
> >
> > > Am 06.05.2014 22:19, schrieb Eduardo Habkost:
> > > > On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> > > >> On Tue, 6 May 2014 11:42:56 -0300
> > > >> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > >>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov
wrote:
> > > >>>> On Fri, 2 May 2014 11:43:05 -0300
> > > >>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > >>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor
Mammedov wrote:
> > > >>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
> > > >>>>>> Eduardo Habkost <ehabkost(a)redhat.com>
wrote:
> > > >>>>>>> This series allows management code to use
object-add on X86CPU subclasses, so it
> > > >>>>>> Is there any reason why "device-add"
couldn't be used?
> > > >>>>> It needs to work with "-machine none",
device_add requires a bus to
> > > >>>>> exist, and there is no icc-bus on machine_none.
> > > >>>> The thing is that CPUID is a function of machine so
using
> > > >>>> "-machine none" will provide only approximately
accurate data.
> > > >>>> I'm not sure that retrieved possibly not accurate
data are useful
> > > >>>> for libvirt.
> > > >>> "-cpu host" doesn't depend on machine, and is
the most important thing
> > > >>> right now (because libvirt's checks for host
QEMU/kernel/CPU
> > > >>> capabilities is completely broken).
> > > >> true, but device-add/-cpu host could be used right now to get
the
> > > >> same CPUID data wile using any machine type or default one
without
> > > >> any of this patches.
> > > >
> > > > device_add can't be used with "-machine none".
> > >
> > > I see no reason why we couldn't *make* CPUs work on -machine none.
The
> > > ICC bus and bridge were a hack to make APIC(?) hot-add work in face of
> > > SysBus; if that prohibits other valid uses now, then evaluating
Igor's
> > > memory work for CPU might be an option.
> > Yep, if CPU is hot-plugged as bus-less device.
> > There is a little concern of APIC device if we go that direction since
> > in addition to hotpluggable BUS, BUS provides address-space for APIC MMIO.
> > With that resolved, x86-cpu shouldn't depend on any bus and if there
isn't
> > any current user that uses QOM path to CPU for introspecting (Eduardo's
> > ABI concern), then it could be done in time for 2.1.
>
> Maybe there are no users of the current QOM path, but we do need a
> stable path to allow management to locate the CPU objects. Do we have
> one, already?
>
Can't we add query-cpus QMP command or something like this to hide path
from user.
That would work, too. But why is a dedicated "query-cpus" command better
than something like "qom-list path=/machine/cpus" (that could simply
return a list of links to the actual CPU objects)?
--
Eduardo
4:52 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Thu, 15 May 2014 11:03:49 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
On Thu, May 15, 2014 at 03:48:16PM +0200, Igor Mammedov wrote:
> On Thu, 15 May 2014 10:07:51 -0300
> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>
> > On Thu, May 15, 2014 at 02:35:01PM +0200, Igor Mammedov wrote:
> > > On Tue, 06 May 2014 22:29:24 +0200
> > > Andreas Färber <afaerber(a)suse.de> wrote:
> > >
> > > > Am 06.05.2014 22:19, schrieb Eduardo Habkost:
> > > > > On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> > > > >> On Tue, 6 May 2014 11:42:56 -0300
> > > > >> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > > >>> On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov
wrote:
> > > > >>>> On Fri, 2 May 2014 11:43:05 -0300
> > > > >>>> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > > >>>>> On Fri, May 02, 2014 at 03:45:03PM +0200, Igor
Mammedov wrote:
> > > > >>>>>> On Wed, 30 Apr 2014 17:29:28 -0300
> > > > >>>>>> Eduardo Habkost <ehabkost(a)redhat.com>
wrote:
> > > > >>>>>>> This series allows management code to
use object-add on X86CPU subclasses, so it
> > > > >>>>>> Is there any reason why
"device-add" couldn't be used?
> > > > >>>>> It needs to work with "-machine none",
device_add requires a bus to
> > > > >>>>> exist, and there is no icc-bus on machine_none.
> > > > >>>> The thing is that CPUID is a function of machine so
using
> > > > >>>> "-machine none" will provide only
approximately accurate data.
> > > > >>>> I'm not sure that retrieved possibly not
accurate data are useful
> > > > >>>> for libvirt.
> > > > >>> "-cpu host" doesn't depend on machine, and
is the most important thing
> > > > >>> right now (because libvirt's checks for host
QEMU/kernel/CPU
> > > > >>> capabilities is completely broken).
> > > > >> true, but device-add/-cpu host could be used right now to
get the
> > > > >> same CPUID data wile using any machine type or default one
without
> > > > >> any of this patches.
> > > > >
> > > > > device_add can't be used with "-machine none".
> > > >
> > > > I see no reason why we couldn't *make* CPUs work on -machine
none. The
> > > > ICC bus and bridge were a hack to make APIC(?) hot-add work in face
of
> > > > SysBus; if that prohibits other valid uses now, then evaluating
Igor's
> > > > memory work for CPU might be an option.
> > > Yep, if CPU is hot-plugged as bus-less device.
> > > There is a little concern of APIC device if we go that direction since
> > > in addition to hotpluggable BUS, BUS provides address-space for APIC
MMIO.
> > > With that resolved, x86-cpu shouldn't depend on any bus and if there
isn't
> > > any current user that uses QOM path to CPU for introspecting
(Eduardo's
> > > ABI concern), then it could be done in time for 2.1.
> >
> > Maybe there are no users of the current QOM path, but we do need a
> > stable path to allow management to locate the CPU objects. Do we have
> > one, already?
> >
>
> Can't we add query-cpus QMP command or something like this to hide path
> from user.
That would work, too. But why is a dedicated "query-cpus" command better
than something like "qom-list path=/machine/cpus" (that could simply
return a list of links to the actual CPU objects)?
So that not to stall the work on
deciding on
- if exposing not yet stables QOM paths as stable ABI is a good thing, I
recall Andreas objecting to using QOM paths with device hotplug
- what paths to CPUs should be wrt stalled topology discussion
--
Eduardo
--
Regards,
Igor
5:16 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Fri, May 16, 2014 at 04:52:21PM +0200, Igor Mammedov wrote:
On Thu, 15 May 2014 11:03:49 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> On Thu, May 15, 2014 at 03:48:16PM +0200, Igor Mammedov wrote:
[...]
> >
> > Can't we add query-cpus QMP command or something like this to hide path
> > from user.
>
> That would work, too. But why is a dedicated "query-cpus" command better
> than something like "qom-list path=/machine/cpus" (that could simply
> return a list of links to the actual CPU objects)?
So that not to stall the work on deciding on
- if exposing not yet stables QOM paths as stable ABI is a good thing, I
recall Andreas objecting to using QOM paths with device hotplug
This surprises me.
- what paths to CPUs should be wrt stalled topology discussion
I don't see why it depends on the topology discussion: if we are capable
of keeping "query-cpus" working after we introduce the topology
hierarchy, I believe we are perfectly capable of keeping symlinks on
"/machine/cpus" working, too. Even if we change the actual paths later
and introduce a more complex QOM hierarchy somewhere else.
Isn't the reuse of infrastructure for list/get/set operations the whole
point of QOM?
--
Eduardo
4:57 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
Am 15.05.2014 14:35, schrieb Igor Mammedov:
PS:
As side effect cpu/apic will disappear from "info qtree" HMP command output.
Solutions are already on the list and in need of feedback:
http://patchwork.ozlabs.org/patch/317224/
http://patchwork.ozlabs.org/patch/343136/
http://patchwork.ozlabs.org/patch/347064/
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
12:13 a.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On 05/06/2014 02:19 PM, Eduardo Habkost wrote:
> IMHO, libvirt side should take advantage of information QEMU
already
> provides.
>
Current API requires re-running QEMU to query the information. This
series allows it to be run with the "-machine none" QEMU instance that
is already run by libvirt.
Therein is the reason libvirt isn't using what qemu already has -
spawning multiple qemu instances (one per reported machine type)
multiplied by the number of qemu binaries does not scale well, when
compared to starting a single qemu -machine none, and doing all queries
on that one machine. So the point of this patch is getting us closer to
the point where libvirt can learn accurate cpu model information for
multiple machines all from a single qemu invocation.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
2:14 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Tue, 6 May 2014 17:19:57 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> On Tue, 6 May 2014 11:42:56 -0300
> Eduardo Habkost <ehabkost(a)redhat.com> wrote:
>
> > On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
> > > On Fri, 2 May 2014 11:43:05 -0300
> > > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > >
> > > > On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> > > > > On Wed, 30 Apr 2014 17:29:28 -0300
> > > > > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > > >
> > > > > > This series allows management code to use object-add on
X86CPU subclasses, so it
> > > > > Is there any reason why "device-add" couldn't be
used?
> > > >
> > > > It needs to work with "-machine none", device_add requires
a bus to
> > > > exist, and there is no icc-bus on machine_none.
> > > The thing is that CPUID is a function of machine so using
> > > "-machine none" will provide only approximately accurate data.
> > > I'm not sure that retrieved possibly not accurate data are useful
> > > for libvirt.
> >
> > "-cpu host" doesn't depend on machine, and is the most important
thing
> > right now (because libvirt's checks for host QEMU/kernel/CPU
> > capabilities is completely broken).
> true, but device-add/-cpu host could be used right now to get the
> same CPUID data wile using any machine type or default one without
> any of this patches.
device_add can't be used with "-machine none".
Well, does caller need
to use -machine in this case at all?
Why not call QEMU with default machine type and get the same info
using device_add ??
>
> >
> > About machine-type data: currently libvirt has no concept of
> > per-machine-type CPU model data, anyway. We (and libvirt) will need to
> > address this eventually, but considering our track record, I bet the
> > QEMU community will take a few years to finally provide that info to
> > libvirt.
> I don't think QEMU is issue here, libvirt can use device-add to
> probe accurate CPUID on all CPU models on a given machine type now.
> libvirt should be fixed to care about machine type and use it to get
> correct CPUID data that QEMU provides.
True, it should. But we still need a solution for the "-cpu host" problem.
As you've said before '-cpu host' doesn't depend on machine type so
libvirt could use "device_add 'host-cpu'" with default or any other
PC machine type right now.
>
> >
> > In the meantime, we have a partial solution that fits the current
> > libvirt data model and is better than the current state (where libvirt
> > has to duplicate the CPU model data).
> Replacing one set of inaccurate CPUIDs with another is hardly solution.
We could continue arguing about this, but let's ignore the issue about
probing for CPU model information by now, and let's focus on host
capability probing ("-cpu host"), then.
How do you propose fixing that in a reasonable time (in QEMU 2.1)
without requiring libvirt to re-run QEMU?
Wouldn't "-cpu host" or
alternative device_add command with default machine
be sufficient?
>
> >
> > Maybe they will use this only for "host", maybe they will use this
for
> > all the other CPU models, we are just providing the mechanism, it's
> > their decision to use it or not.
> As I've said above libvirt could use device-add xxx-host or -cpu host
> to get it and second point I object to is providing yet another way
> to produce inaccurate CPUID info (libvirt has one already) and to do
> so hack [patches 1-3] CPU infrastructure to run out of context it's
> supposed to run in. While current API already allows to get correct
> CPUID data.
>
> IMHO, libvirt side should take advantage of information QEMU already
> provides.
>
Current API requires re-running QEMU to query the information. This
series allows it to be run with the "-machine none" QEMU instance that
is already run by libvirt.
> >
> >
> > >
> > > >
> > > > The first thing I considered was making icc-bus user-creatable. Then
I
> > > > noticed it wouldn't work because object-add always add objects
to
> > > > /objects, not inside the qdev hierarchy (that's where device_add
looks
> > > > for the bus).
> > > >
> > > > So, allowing device_add could be possible, but would require
changing
> > > > more basic infrastructure: either allowing bus-less devices on
> > > > device_add, or allowing device_add to add devices outside the qdev
> > > > hierarchy, or allowing object-add to create objects outside
/objects.
> > > >
> > > > Simply making CPU objects work with object-add was much simpler and
less
> > > > intrusive. And it had the interesting side-effect of _not_ doing
things
> > > > that are not required for CPU model probing (like creating an actual
> > > > VCPU thread).
> > > >
> > > > >
> > > > >
> > > > > > can use it to probe for CPU model information without
re-running QEMU. The main
> > > > > > use case for this is to allow management code to create CPU
objects and query
> > > > > > the "feature-words" and
"filtered-features" properties on the new objects, to
> > > > > > find out which features each CPU model needs, and to do the
same using the
> > > > > > "host" CPU model to check which features can be
enabled in a given host.
> > > > > >
> > > > > > There's experimental libvirt code to use the new
command at:
> > > > > >
https://github.com/ehabkost/libvirt/tree/work/cpu-feature-word-query
> > > > > > The experimental code just create the CPU objects to query
for feature
> > > > > > information, but doesn't do anything with that data.
> > > > > >
> > > > > > Eduardo Habkost (5):
> > > > > > cpu: Initialize cpu->stopped=true earlier
> > > > > > cpu: Don't try to pause CPUs if they are already
stopped
> > > > > > pc: Don't crash on apic_accept_pic_intr() if CPU has
no apic_state
> > > > > > target-i386: Make CPU objects user-creatable
> > > > > > target-i386: Report QOM class name for CPU definitions
> > > > > >
> > > > > > cpus.c | 13 ++++++++++---
> > > > > > exec.c | 1 +
> > > > > > hw/i386/pc.c | 2 +-
> > > > > > qapi-schema.json | 6 +++++-
> > > > > > target-i386/cpu.c | 7 +++++++
> > > > > > 5 files changed, 24 insertions(+), 5 deletions(-)
> > > > > >
> > > > >
> > > >
> > >
> >
> > --
> > Eduardo
> >
>
>
> --
> Regards,
> Igor
3:35 p.m.
New subject: [libvirt] [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
On Thu, May 15, 2014 at 02:14:18PM +0200, Igor Mammedov wrote:
On Tue, 6 May 2014 17:19:57 -0300
Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> On Tue, May 06, 2014 at 10:01:11PM +0200, Igor Mammedov wrote:
> > On Tue, 6 May 2014 11:42:56 -0300
> > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> >
> > > On Tue, May 06, 2014 at 09:22:38AM +0200, Igor Mammedov wrote:
> > > > On Fri, 2 May 2014 11:43:05 -0300
> > > > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > >
> > > > > On Fri, May 02, 2014 at 03:45:03PM +0200, Igor Mammedov wrote:
> > > > > > On Wed, 30 Apr 2014 17:29:28 -0300
> > > > > > Eduardo Habkost <ehabkost(a)redhat.com> wrote:
> > > > > >
> > > > > > > This series allows management code to use object-add
on X86CPU subclasses, so it
> > > > > > Is there any reason why "device-add" couldn't
be used?
> > > > >
> > > > > It needs to work with "-machine none", device_add
requires a bus to
> > > > > exist, and there is no icc-bus on machine_none.
> > > > The thing is that CPUID is a function of machine so using
> > > > "-machine none" will provide only approximately accurate
data.
> > > > I'm not sure that retrieved possibly not accurate data are
useful
> > > > for libvirt.
> > >
> > > "-cpu host" doesn't depend on machine, and is the most
important thing
> > > right now (because libvirt's checks for host QEMU/kernel/CPU
> > > capabilities is completely broken).
> > true, but device-add/-cpu host could be used right now to get the
> > same CPUID data wile using any machine type or default one without
> > any of this patches.
>
> device_add can't be used with "-machine none".
Well, does caller need to use -machine in this case at all?
Why not call QEMU with default machine type and get the same info
using device_add ??
I guess the explanation for "-machine none" is at:
commit b4a738bf93c3137b92d532e59d60edccc4e1ea96
Author: Anthony Liguori <aliguori(a)us.ibm.com>
Date: Wed Aug 22 15:22:05 2012 -0500
boards: add a 'none' machine type to all platforms
This allows any QEMU binary to be executed with:
$QEMU_BINARY -M none -qmp stdio
Without errors from missing options that are required by various boards. This
also provides a mode that we can use in the future to construct machines
entirely through QMP commands.
Cc: Daniel Berrange <berrange(a)redhat.com>
Cc: Markus Armbruster <armbru(a)redhat.com>
Signed-off-by: Anthony Liguori <aliguori(a)us.ibm.com>
libvirt runs QEMU with "-machine none" before it knows anything about the QEMU
binaries. There are many target architectures where the default machine-type
won't work without extra options.
15 of the 26 qemu-system-* binaries on my Fedora 20 system failed to run as:
$QEMU -nodefaults -no-user-config -nographic -monitor stdio
(All of them ran happily when I added "-M none".)
>
> >
> > >
> > > About machine-type data: currently libvirt has no concept of
> > > per-machine-type CPU model data, anyway. We (and libvirt) will need to
> > > address this eventually, but considering our track record, I bet the
> > > QEMU community will take a few years to finally provide that info to
> > > libvirt.
> > I don't think QEMU is issue here, libvirt can use device-add to
> > probe accurate CPUID on all CPU models on a given machine type now.
> > libvirt should be fixed to care about machine type and use it to get
> > correct CPUID data that QEMU provides.
>
> True, it should. But we still need a solution for the "-cpu host"
problem.
As you've said before '-cpu host' doesn't depend on machine type so
libvirt could use "device_add 'host-cpu'" with default or any other
PC machine type right now.
But not with "-machine none".
--
Eduardo
3779
days inactive
3795
days old
27 comments
5 participants
participants (5)
-
Andreas Färber -
Eduardo Habkost -
Eric Blake -
Igor Mammedov -
Paolo Bonzini