[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] s390: Storage key global access
From: |
Jason J. Herne |
Subject: |
Re: [Qemu-devel] [PATCH] s390: Storage key global access |
Date: |
Wed, 26 Feb 2014 09:57:15 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
On 02/25/2014 02:34 PM, Andreas Färber wrote:
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.
Andreas,
I believe I understood about 90% of what you were asking for. I had made
many
of the changes you requested. The last version of my patches can be seen
here
https://www.mail-archive.com/address@hidden/msg201796.html
Most of the requested changes should be found within this set of patches.
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.
As per your original suggestion to try link<>, I wrote the code to do
exactly
that. Please see patch 6/8 in the above series.
I have a version of these patches rebased for the latest master, but my test
system is currently in use. I would like a chance to regression test them
before I post them. I anticipate I should be able to do this today.
At your option, you may opt to review the patches as posted at the above
link.
While some modifications have since been made, the overall design and
function
is the same.
I look forward to your comments. Thank you for your time.
--
-- Jason J. Herne (address@hidden)