From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIJ5p-00014b-5p for qemu-devel@nongnu.org; Tue, 25 Feb 2014 09:34:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIJ5g-0006az-3G for qemu-devel@nongnu.org; Tue, 25 Feb 2014 09:34:45 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:33517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIJ5f-0006a2-Vd for qemu-devel@nongnu.org; Tue, 25 Feb 2014 09:34:36 -0500 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 25 Feb 2014 09:34:34 -0500 Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 775786E8041 for ; Tue, 25 Feb 2014 09:34:26 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by b01cxnp23033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s1PEYVtx5046726 for ; Tue, 25 Feb 2014 14:34:31 GMT Received: from d01av03.pok.ibm.com (localhost [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s1PEYU6H031409 for ; Tue, 25 Feb 2014 09:34:31 -0500 Message-ID: <530CA9F6.6010202@linux.vnet.ibm.com> Date: Tue, 25 Feb 2014 09:34:30 -0500 From: "Jason J. Herne" MIME-Version: 1.0 References: <1390405693-15696-1-git-send-email-jjherne@us.ibm.com> <52F3A801.2030405@de.ibm.com> In-Reply-To: <52F3A801.2030405@de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] s390: Storage key global access Reply-To: jjherne@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger , "Jason J. Herne" , afaerber@suse.de, agraf@suse.de, qemu-devel@nongnu.org On 02/06/2014 10:19 AM, Christian Borntraeger wrote: > On 22/01/14 16:48, Jason J. Herne wrote: >> From: "Jason J. Herne" >> >> Introduces global access to storage key data so we can set it for each cpu in >> the S390 cpu initialization routine. >> >> Signed-off-by: Jason J. Herne >> --- >> hw/s390x/s390-virtio-ccw.c | 3 +-- >> hw/s390x/s390-virtio.c | 6 +++--- >> hw/s390x/s390-virtio.h | 2 +- >> target-s390x/cpu.h | 3 +++ >> 4 files changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c >> index 733d988..62319b9 100644 >> --- a/hw/s390x/s390-virtio-ccw.c >> +++ b/hw/s390x/s390-virtio-ccw.c >> @@ -80,7 +80,6 @@ static void ccw_init(QEMUMachineInitArgs *args) >> MemoryRegion *sysmem = get_system_memory(); >> MemoryRegion *ram = g_new(MemoryRegion, 1); >> int shift = 0; >> - uint8_t *storage_keys; >> int ret; >> VirtualCssBus *css_bus; >> >> @@ -112,7 +111,7 @@ static void ccw_init(QEMUMachineInitArgs *args) >> storage_keys = g_malloc0(my_ram_size / TARGET_PAGE_SIZE); >> >> /* init CPUs */ >> - s390_init_cpus(args->cpu_model, storage_keys); >> + s390_init_cpus(args->cpu_model); >> >> if (kvm_enabled()) { >> kvm_s390_enable_css_support(s390_cpu_addr2state(0)); >> diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c >> index 7adf92a..804483f 100644 >> --- a/hw/s390x/s390-virtio.c >> +++ b/hw/s390x/s390-virtio.c >> @@ -53,6 +53,7 @@ >> >> static VirtIOS390Bus *s390_bus; >> static S390CPU **ipi_states; >> +uint8_t *storage_keys; > > This would add another global variable. I am find with this right now > but somewhen in the future we might want to take care of storage keys > in regard to migration as well. > > Could we add a container-device/memory? We could make it > a child of the machine then? Dont know if that will work out with > migration, though. > > Christian Sorry for the delay in responding to this. I've been busy tracking down some kernel bugs. I'm not 100% sure what a storage key device would look like at the moment. However I agree that a device is the cleanest approach. I support sticking with the current implementation for now as it gets us cpu hotplug now, as opposed to later. I do have some concerns with respect to migration if storage keys are a separate device. I think that is a discussion for a different time though. 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 :). -- -- Jason J. Herne (jjherne@linux.vnet.ibm.com)