qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] cpu: Register QOM links at /machine/cpus/<index


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] cpu: Register QOM links at /machine/cpus/<index>
Date: Mon, 4 May 2015 10:37:02 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, May 04, 2015 at 03:16:16PM +0200, Igor Mammedov wrote:
> On Mon, 04 May 2015 11:59:52 +0200
> Paolo Bonzini <address@hidden> wrote:
> 
> > 
> > 
> > On 04/05/2015 11:47, Igor Mammedov wrote:
> > > On Thu, 30 Apr 2015 16:19:07 -0300
> > > Eduardo Habkost <address@hidden> wrote:
> > > 
> > > > This will provide a predictable path for the CPU objects, and a
> > > > more powerful alternative for the query-cpus QMP command, as now
> > > > every QOM property on CPU objects can be easily queried.
> > > 
> > > provided the way cpu_index is generated, path won't be
> > > predictable/stable with CPU unplug. I'd rather use DEVICE->id
> > > instead of cpu_index.
> > 
> > Can we use the APIC id then?  Perhaps wrapped with a CPUState-level
> > method get_stable_processor_id()?
> We have CPUClass->get_arch_id() which results in APIC id for
> target-i386.
> But I'd rather see an arbitrary DEVICE->id as index/name, that way
> when -device cpu-foo,id=cpuXXX becomes functional we would have
> 1:1 mapping between CLI and /machine/cpus/ view.

An arbitrary device ID sounds better to me, because it allows us to
change guest-visible behavior without breaking QMP client expectations.

The only question is what should be the default device ID for the CPUs
created by -smp and cpu-add. I was going to suggest get_arch_id(), but
cpu_index may be a better candidate for the same reason above: it is
truly an arbitrary ID that doesn't depend on guest-visible bits.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]