[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] cpu: Register QOM links at /machine/cpus/<index
Re: [Qemu-devel] [PATCH] cpu: Register QOM links at /machine/cpus/<index>
Mon, 4 May 2015 11:05:58 -0300
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.
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.
 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.