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

[Eduardo Habkost]

On Mon, May 04, 2015 at 03:19:32PM +0200, Paolo Bonzini wrote:
> 
> 
> On 04/05/2015 15:16, Igor Mammedov wrote:
> >> > 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.
> 
> CPUs would already be available at /machine/peripheral.  I think aliases
> should provide alternative indexing whenever possible---not simply
> filter by device type.

Could you clarify what you mean by "alternative indexing"?

All I am trying to provide right now is having a predictable path for
CPUs, it doesn't matter if using -device, device_add, -smp, or cpu-add.
Filtering by device type is not what I need, here. If we can make the
CPU QOM path predictable inside /machine/peripheral or anywhere else,
that would be enough to me[1].

device IDs are predictable when using -device because they are in the
command-line. And they are predictable for -smp CPUs if we use cpu_index
as default ID.

Making the path depend on guest-visible bits that can change depending
on the architeture or machine would make the path less predictable.

I have an alternative patch that simply adds a "qom-path" field to
query-cpus. If we find out that making commitments about QOM paths is
too hard, I can submit it instead.

[1] Is there anybody or any document that can explain to me what all the
    containers inside /machine mean? I see /machine/peripheral,
    /machine/peripheral-anon, /machine/unattached, here, and I don't
    know what they mean.

-- 
Eduardo