From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WINma-0000tQ-5i for qemu-devel@nongnu.org; Tue, 25 Feb 2014 14:35:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WINmS-0000u0-LO for qemu-devel@nongnu.org; Tue, 25 Feb 2014 14:35:12 -0500 Received: from cantor2.suse.de ([195.135.220.15]:48432 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WINmS-0000nR-Fr for qemu-devel@nongnu.org; Tue, 25 Feb 2014 14:35:04 -0500 Message-ID: <530CF063.3020505@suse.de> Date: Tue, 25 Feb 2014 20:34:59 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1390405693-15696-1-git-send-email-jjherne@us.ibm.com> <52F3A801.2030405@de.ibm.com> <530CA9F6.6010202@linux.vnet.ibm.com> <530CEBD5.3030308@de.ibm.com> In-Reply-To: <530CEBD5.3030308@de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] s390: Storage key global access List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger , jjherne@linux.vnet.ibm.com, "Jason J. Herne" Cc: agraf@suse.de, qemu-devel@nongnu.org Hi, Am 25.02.2014 20:15, schrieb Christian Borntraeger: > On 25/02/14 15:34, Jason J. Herne wrote: >=20 >> 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 stil= l feel this way let me know and I'll post the 4-patch series. If not, I s= till propose this one for s390-next. Thanks :). >=20 > Do you feel your series is ready for upstream, then yet please post the= whole series.=20 > Posting independent things is good, but I feel that the storage key rew= ork 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 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg