Hi, Am 25.02.2014 20:15, schrieb Christian Borntraeger: > On 25/02/14 15:34, Jason J. Herne wrote: > >> Christian, at one point you mentioned that it might be helpful to see this >> patch in the context of the rest of the hotplug patches. If you still feel >> this way let me know and I'll post the 4-patch series. If not, I still >> propose this one for s390-next. Thanks :). > > Do you feel your series is ready for upstream, then yet please post the whole > series. > Posting independent things is good, but I feel that the storage key rework > makes more > sense if the followup patches make clear why.
I had requested changes to that series that apparently I could not communicate in a form Jason could digest, and I have since been caught in downstream work and a backlog of other patches, not getting to writing the alternative myself yet nor will I the next few days. An outline of the idea as far as I remember was dropping the ipi array instead of refactoring it to dynamic allocation and - having discussed that a topology will not be needed - add them as cpu[n] child<s390-cpu> properties of /machine, allowing access via QOM property getters instead of some self-cooked solution. Open question was link<> or child<> property and, if link<>, whether some setter hook in QOM infrastructure may be needed to trigger the hot-add or whether QOM realize event will be sufficient. I'd still be interested in getting vCPU hotplug for s390x in 2.0, so maybe you can re-read my previous comments with a view to making -device and cpu-add work with minimum workarounds on your own? We still don't have model subclasses BTW, do we? 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