Re: [Qemu-devel] [PATCH] s390: Storage key global access

["Andreas Färber" <afaerber@suse.de>]

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