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

[Andreas Färber]

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