qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v8 6/7] s390x/cpu: Add error handling to cpu cre


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v8 6/7] s390x/cpu: Add error handling to cpu creation
Date: Mon, 7 Mar 2016 11:12:14 +0100

On Mon, 7 Mar 2016 11:02:11 +0100
David Hildenbrand <address@hidden> wrote:

> > > After all the discussions about
> > > -device-add s390-cpu,id=XX
> > > 
> > > As substitute/addition in the future for hotplug it is the straightforward
> > > approach to allow setting the id as property. Nobody knows what crazy new
> > > hotplug method we will come up with. But doing it the device way with 
> > > properties
> > > cannot be wrong. And the id is a fundamental concept of a vcpu (cpu-add 
> > > id=XX).    
> > with device_add 'id' is not a vcpu concept but and arbitrary user supplied 
> > string
> > property owned by Device. But since s390 matches current x86 thread based 
> > model it could be migrated to device_add the same way, for example:
> >   device_add s390-cpu,thread=XX  
> 
> So should we name the property thread then?
> Looks like the id property is really special.
> 
> What do you suggest?
I plan to add 'thread' property to x86-cpu, so you could the same for
s390 when the time for device_add comes there.

> 
> >   
> > > 
> > > So I'd like to avoid reworking everything again, to realize later that we
> > > want it as a property and rewriting it once again.    
> > for s390, the thing about not rewriting everything once again could be
> > replacing places where cpu_index is used with CpuClass.arch_id().
> > arch_id() defaults to cpu_index but you can later override it with
> > your own id (whatever s390 uses for identifying cpus on baremetal)
> > so switching to device_add won't break anything.  
> 
> Okay, this way we could get rid of cpu_index later.
> 
> David
> 
> 




reply via email to

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