[Qemu-devel] [PATCH 0/5] s390: Support for Hotplug of Standby Memory

originally done by Jeng-Fang (Nick) Wang. Matthew Rosato (5): Add the standby-mem machine option virtio-ccw: Include standby memory when calculating storage increment target-s390: Check for standby memory specification sclp-s390: Define new SCLP codes and structures sclp-s390: Add memory

[Qemu-devel] [PATCH 1/5] Add the standby-mem machine option

Add the machine=...,standby-mem={size} option and associated documentation. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- qemu-options.hx |6 +- vl.c|6 ++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/qemu-options.hx b/qemu-options.hx

[Qemu-devel] [PATCH 4/5] sclp-s390: Define new SCLP codes and structures

Define new SCLP codes and structures that will be needed for s390 memory hotplug. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c |2 +- include/hw/s390x/sclp.h | 46 ++ 2 files changed, 47 insertions(+), 1

[Qemu-devel] [PATCH 2/5] virtio-ccw: Include standby memory when calculating storage increment

When determining the memory increment size, include the standby memory as well as the core memory. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 30 +- target-s390x/cpu.h |4 2 files changed, 29

[Qemu-devel] [PATCH 3/5] target-s390: Check for standby memory specification

When machine=...,standby-mem={size} has been specified, convert the value to bytes and store it for use. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- target-s390x/kvm.c | 16 1 file changed, 16 insertions(+) diff --git a/target-s390x/kvm.c b/target-s390x

[Qemu-devel] [PATCH 5/5] sclp-s390: Add memory hotplug SCLPs

Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c | 233

Re: [Qemu-devel] [PATCH 1/5] Add the standby-mem machine option

On 12/17/2013 05:09 AM, Paolo Bonzini wrote: Il 16/12/2013 21:51, Matthew Rosato ha scritto: Add the machine=...,standby-mem={size} option and associated documentation. See how Igor Mammedov's x86 memory hotplug instead added -m NN,maxmem=NN. You could use these two patches: http

Re: [Qemu-devel] [PATCH 3/5] target-s390: Check for standby memory specification

On 12/16/2013 04:25 PM, Alexander Graf wrote: On 16.12.2013, at 21:51, Matthew Rosato mjros...@linux.vnet.ibm.com wrote: When machine=...,standby-mem={size} has been specified, convert the value to bytes and store it for use. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com

Re: [Qemu-devel] [PATCH 5/5] sclp-s390: Add memory hotplug SCLPs

On 12/16/2013 04:42 PM, Alexander Graf wrote: On 16.12.2013, at 21:51, Matthew Rosato mjros...@linux.vnet.ibm.com wrote: Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off

Re: [Qemu-devel] [PATCH 5/5] sclp-s390: Add memory hotplug SCLPs

On 12/16/2013 06:18 PM, Alexander Graf wrote: On 16.12.2013, at 22:42, Alexander Graf ag...@suse.de wrote: On 16.12.2013, at 21:51, Matthew Rosato mjros...@linux.vnet.ibm.com wrote: [...] +} +} +} +sccb-h.response_code = cpu_to_be16

Re: [Qemu-devel] [PATCH v6 3/3] sclp-s390: Add memory hotplug SCLPs

On 07/29/2014 08:17 AM, Christian Borntraeger wrote: On 30/06/14 16:00, Matthew Rosato wrote: Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Signed-off-by: Matthew Rosato mjros

[Qemu-devel] [PATCH v7 0/4] s390: Support for Hotplug of Standby Memory

of object_property_find(). Matthew Rosato (4): sclp-s390: Add device to manage s390 memory hotplug virtio-ccw: Include standby memory when calculating storage increment s390-virtio: Apply same memory boundaries as virtio-ccw sclp-s390: Add memory hotplug SCLPs hw/s390x/s390-virtio-ccw.c | 46

[Qemu-devel] [PATCH v7 2/4] virtio-ccw: Include standby memory when calculating storage increment

When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 46 qemu-options.hx|3 ++- target-s390x/cpu.h

[Qemu-devel] [PATCH v7 3/4] s390-virtio: Apply same memory boundaries as virtio-ccw

Although s390-virtio won't support memory hotplug, it should enforce the same memory boundaries so that it can use shared codepaths (like read_SCP_info). Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio.c | 15 +-- 1 file changed, 9 insertions

[Qemu-devel] [PATCH v7 1/4] sclp-s390: Add device to manage s390 memory hotplug

Add sclpMemoryHotplugDev to contain associated data structures, etc. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c | 30 ++ include/hw/s390x/sclp.h | 20 2 files changed, 50 insertions(+) diff --git

[Qemu-devel] [PATCH v7 4/4] sclp-s390: Add memory hotplug SCLPs

Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c| 259

Re: [Qemu-devel] [PATCH] qmp: object-add: Validate class before creating object

) { goto out; I'm no expert here, but this seems straightforward: Reviewed-by: Matthew Rosato mjros...@linux.vnet.ibm.com Also applied and tested both error paths, so feel to consider it: Tested-by: Matthew Rosato mjros...@linux.vnet.ibm.com

Re: [Qemu-devel] [PATCH v2] qmp: object-add: Validate class before creating object

-by: Matthew Rosato mjros...@linux.vnet.ibm.com Tested-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- qmp.c | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/qmp.c b/qmp.c index 87a28f7..9a93ab1 100644 --- a/qmp.c +++ b/qmp.c @@ -540,14 +540,27

[Qemu-devel] [PATCH v5 0/3] s390: Support for Hotplug of Standby Memory

hotplug device parent to sysbus. * Pulled latest version of Igor's patch. Matthew Rosato (3): sclp-s390: Add device to manage s390 memory hotplug virtio-ccw: Include standby memory when calculating storage increment sclp-s390: Add memory hotplug SCLPs hw/s390x/s390-virtio-ccw.c | 46

[Qemu-devel] [PATCH v5 2/3] virtio-ccw: Include standby memory when calculating storage increment

When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 46 qemu-options.hx|3 ++- target-s390x/cpu.h

[Qemu-devel] [PATCH v5 1/3] sclp-s390: Add device to manage s390 memory hotplug

Add sclpMemoryHotplugDev to contain associated data structures, etc. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c | 30 ++ include/hw/s390x/sclp.h | 20 2 files changed, 50 insertions(+) diff --git

[Qemu-devel] [PATCH v5 3/3] sclp-s390: Add memory hotplug SCLPs

Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c| 259

Re: [Qemu-devel] [PATCH v5 1/3] sclp-s390: Add device to manage s390 memory hotplug

On 06/25/2014 10:53 AM, Igor Mammedov wrote: On Wed, 25 Jun 2014 10:26:58 -0400 Matthew Rosato mjros...@linux.vnet.ibm.com wrote: Add sclpMemoryHotplugDev to contain associated data structures, etc. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c

Re: [Qemu-devel] [PATCH v5 3/3] sclp-s390: Add memory hotplug SCLPs

On 06/26/2014 09:14 AM, Christian Borntraeger wrote: On 25/06/14 16:27, Matthew Rosato wrote: Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros

[Qemu-devel] [PATCH v6 2/3] virtio-ccw: Include standby memory when calculating storage increment

When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 46 qemu-options.hx|3 ++- target-s390x/cpu.h

[Qemu-devel] [PATCH v6 3/3] sclp-s390: Add memory hotplug SCLPs

Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c| 259 ++-- target

[Qemu-devel] [PATCH v6 1/3] sclp-s390: Add device to manage s390 memory hotplug

Add sclpMemoryHotplugDev to contain associated data structures, etc. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c | 30 ++ include/hw/s390x/sclp.h | 20 2 files changed, 50 insertions(+) diff --git

[Qemu-devel] [PATCH v6 0/3] s390: Support for Hotplug of Standby Memory

. * Pulled latest version of Igor's patch. Matthew Rosato (3): sclp-s390: Add device to manage s390 memory hotplug virtio-ccw: Include standby memory when calculating storage increment sclp-s390: Add memory hotplug SCLPs hw/s390x/s390-virtio-ccw.c | 46 +-- hw/s390x/sclp.c| 289

Re: [Qemu-devel] [PATCH v3 3/4] virtio-ccw: Include standby memory when calculating storage increment

On 05/12/2014 03:43 AM, Christian Borntraeger wrote: On 07/05/14 20:05, Matthew Rosato wrote: When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 44

Re: [Qemu-devel] [PATCH v3 3/4] virtio-ccw: Include standby memory when calculating storage increment

On 05/13/2014 09:43 AM, Alexander Graf wrote: On 13.05.14 15:16, Matthew Rosato wrote: On 05/12/2014 03:43 AM, Christian Borntraeger wrote: On 07/05/14 20:05, Matthew Rosato wrote: When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew

Re: [Qemu-devel] [PATCH v3 4/4] sclp-s390: Add memory hotplug SCLPs

On 05/12/2014 03:35 AM, Christian Borntraeger wrote: On 07/05/14 20:05, Matthew Rosato wrote: Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros

[Qemu-devel] [PATCH v4 2/4] sclp-s390: Add device to manage s390 memory hotplug

Add sclpMemoryHotplugDev to contain associated data structures, etc. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c | 38 ++ include/hw/s390x/sclp.h | 20 2 files changed, 58 insertions(+) diff

[Qemu-devel] [PATCH v4 3/4] virtio-ccw: Include standby memory when calculating storage increment

When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 46 qemu-options.hx|3 ++- target-s390x/cpu.h

[Qemu-devel] [PATCH v4 0/4] s390: Support for Hotplug of Standby Memory

object that encapsulate variables used by s390 memory hotplug. Patches 4 and 5 adjusted to use this object. * Added additional code comments and other minor changes per Alexander Graf's comments Igor Mammedov (1): vl.c: extend -m option to support options for memory hotplug Matthew

[Qemu-devel] [PATCH v4 1/4] vl.c: extend -m option to support options for memory hotplug

. Signed-off-by: Igor Mammedov imamm...@redhat.com Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- include/hw/boards.h |2 ++ qemu-options.hx |9 ++--- vl.c| 51 +++ 3 files changed, 59 insertions(+), 3

[Qemu-devel] [PATCH v4 4/4] sclp-s390: Add memory hotplug SCLPs

Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c| 259

[Qemu-devel] [PATCH v2 0/5] s390: Support for Hotplug of Standby Memory

to use this object. * Added additional code comments and other minor changes per Alexander Graf's comments Igor Mammedov (2): vl: convert -m to QemuOpts vl.c: extend -m option to support options for memory hotplug Matthew Rosato (3): sclp-s390: Add device to manage s390 memory hotplug

[Qemu-devel] [PATCH v2 3/5] sclp-s390: Add device to manage s390 memory hotplug

Add sclpMemoryHotplugDev to contain associated data structures, etc. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c | 32 include/hw/s390x/sclp.h | 19 +++ 2 files changed, 51 insertions(+) diff --git

[Qemu-devel] [PATCH v2 1/5] vl: convert -m to QemuOpts

From: Igor Mammedov imamm...@redhat.com Adds option to -m mem - startup memory amount For compatibility with legacy CLI if suffix-less number is passed, it assumes amount in Mb. Otherwise user is free to use suffixed number using suffixes b,k/K,M,G Signed-off-by: Igor Mammedov

[Qemu-devel] [PATCH v2 2/5] vl.c: extend -m option to support options for memory hotplug

From: Igor Mammedov imamm...@redhat.com Add following parameters: slots - total number of hotplug memory slots maxmem - maximum possible memory slots and maxmem should go in pair and maxmem should be greater than mem for memory hotplug to be enabled. Signed-off-by: Igor Mammedov

[Qemu-devel] [PATCH v2 5/5] sclp-s390: Add memory hotplug SCLPs

Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c| 244

[Qemu-devel] [PATCH v2 4/5] virtio-ccw: Include standby memory when calculating storage increment

When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 42 ++ target-s390x/cpu.h |3 +++ 2 files changed, 37 insertions

[Qemu-devel] [PATCH] sclp-s390: Define new SCLP codes and structures

Define new SCLP codes and structures that will be needed for s390 memory hotplug. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- include/hw/s390x/sclp.h | 35 +++ 1 file changed, 35 insertions(+) Note: As requested, this patch is fit on: git

[Qemu-devel] [PATCH v3 2/4] sclp-s390: Add device to manage s390 memory hotplug

Add sclpMemoryHotplugDev to contain associated data structures, etc. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c | 32 include/hw/s390x/sclp.h | 19 +++ 2 files changed, 51 insertions(+) diff --git

[Qemu-devel] [PATCH v3 0/4] s390: Support for Hotplug of Standby Memory

changes per Alexander Graf's comments Igor Mammedov (1): vl.c: extend -m option to support options for memory hotplug Matthew Rosato (3): sclp-s390: Add device to manage s390 memory hotplug virtio-ccw: Include standby memory when calculating storage increment sclp-s390: Add memory hotplug

[Qemu-devel] [PATCH v3 1/4] vl.c: extend -m option to support options for memory hotplug

. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- include/hw/boards.h |2 ++ qemu-options.hx |9 ++--- vl.c| 51 +++ 3 files changed, 59 insertions(+), 3 deletions(-) diff --git a/include/hw/boards.h b

[Qemu-devel] [PATCH v3 4/4] sclp-s390: Add memory hotplug SCLPs

Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c| 245

[Qemu-devel] [PATCH v3 3/4] virtio-ccw: Include standby memory when calculating storage increment

When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 44 target-s390x/cpu.h |3 +++ 2 files changed, 39 insertions

Re: [Qemu-devel] [PATCH v3 1/4] vl.c: extend -m option to support options for memory hotplug

On 05/07/2014 02:50 PM, Alexander Graf wrote: On 05/07/2014 08:05 PM, Matthew Rosato wrote: From: Igor Mammedov imamm...@redhat.com From: Igor Mammedov imamm...@redhat.com Add following parameters: slots - total number of hotplug memory slots maxmem - maximum possible memory slots

Re: [Qemu-devel] [PATCH v2 0/5] s390: Support for Hotplug of Standby Memory

On 02/24/2014 04:30 PM, Matthew Rosato wrote: This patchset adds support in s390 for a pool of standby memory, which can be set online/offline by the guest (ie, via chmem). New options, maxmem and slots, are added to the QEMU command line memory parameter to specify the total amount of memory

Re: [Qemu-devel] [PATCH v2 0/5] s390: Support for Hotplug of Standby Memory

On 03/10/2014 10:39 AM, Matthew Rosato wrote: On 02/24/2014 04:30 PM, Matthew Rosato wrote: This patchset adds support in s390 for a pool of standby memory, which can be set online/offline by the guest (ie, via chmem). New options, maxmem and slots, are added to the QEMU command line memory

Re: [Qemu-devel] [PATCH 4/5] sclp-s390: Define new SCLP codes and structures

On 03/20/2014 05:56 AM, Christian Borntraeger wrote: On 16/12/13 21:51, Matthew Rosato wrote: Define new SCLP codes and structures that will be needed for s390 memory hotplug. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c |2 +- include/hw/s390x

Re: [Qemu-devel] [PATCH v6 0/3] s390: Support for Hotplug of Standby Memory

On 06/30/2014 10:00 AM, Matthew Rosato wrote: This patchset adds support in s390 for a pool of standby memory, which can be set online/offline by the guest (ie, via chmem). The standby pool of memory is allocated as the difference between the initial memory setting and the maxmem setting

Re: [Qemu-devel] [PATCH v7 0/4] s390: Support for Hotplug of Standby Memory

On 07/30/2014 02:15 PM, Matthew Rosato wrote: This patchset adds support in s390 for a pool of standby memory, which can be set online/offline by the guest (ie, via chmem). The standby pool of memory is allocated as the difference between the initial memory setting and the maxmem setting

[Qemu-devel] [PATCH v8 1/4] sclp-s390: Add device to manage s390 memory hotplug

Add sclpMemoryHotplugDev to contain associated data structures, etc. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c | 30 ++ include/hw/s390x/sclp.h | 20 2 files changed, 50 insertions(+) diff --git

[Qemu-devel] [PATCH v8 0/4] s390: Support for Hotplug of Standby Memory

in the cover letter. Changes for v5: * Since ACPI memory hotplug is now in, removed Igor's patches from this set. * Updated sclp.c to use object_resolve_path() instead of object_property_find(). Matthew Rosato (4): sclp-s390: Add device to manage s390 memory hotplug virtio-ccw

[Qemu-devel] [PATCH v8 2/4] virtio-ccw: Include standby memory when calculating storage increment

When determining the memory increment size, use the maxmem size if it was specified. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio-ccw.c | 46 qemu-options.hx|3 ++- target-s390x/cpu.h

[Qemu-devel] [PATCH v8 3/4] s390-virtio: Apply same memory boundaries as virtio-ccw

Although s390-virtio won't support memory hotplug, it should enforce the same memory boundaries so that it can use shared codepaths (like read_SCP_info). Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/s390-virtio.c | 15 +-- 1 file changed, 9 insertions

[Qemu-devel] [PATCH v8 4/4] sclp-s390: Add memory hotplug SCLPs

Add memory information to read SCP info and add handlers for Read Storage Element Information, Attach Storage Element, Assign Storage and Unassign Storage. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/s390x/sclp.c| 259

Re: [Qemu-devel] [PATCH] memory: Fix double unref of flatview

On 02/12/2015 12:34 PM, Paolo Bonzini wrote: On 12/02/2015 17:21, Matthew Rosato wrote: Since 374f2981d1 memory: protect current_map by RCU, address_space_update_topology unrefs the old_flatview twice, once by call_rcu and once by direct call. This patch removes the direct call in favor

Re: [Qemu-devel] [PATCH] memory: Fix double unref of flatview

On 02/12/2015 03:43 PM, Paolo Bonzini wrote: On 12/02/2015 20:32, Matthew Rosato wrote: Could it be that the order in which flatview_unref (and therefore memory_region_unref) vs object_unparent(mr) matters (ie, object_unparent should always happen last)? Prior to RCUification, seems like

Re: [Qemu-devel] [PATCH 2/3] pci: split shpc_cleanup and shpc_free

the instance_finalize callback. shpc_free follows the same coding style that Alex suggested for VFIO (i.e. since a test for NULL is requested, clear the field at end). Signed-off-by: Paolo Bonzini pbonz...@redhat.com Reviewed-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/pci-bridge

Re: [Qemu-devel] [PATCH 3/3] docs: clarify memory region lifecycle

On 02/13/2015 09:57 AM, Paolo Bonzini wrote: Now that objects actually obey the rules, document them. Signed-off-by: Paolo Bonzini pbonz...@redhat.com Reviewed-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- docs/memory.txt | 74

[Qemu-devel] [PATCH] memory: Fix double unref of flatview

for a memory region attempts to go negative during hot-unplug of guest memory. Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- memory.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/memory.c b/memory.c index 130152c..d08abe5 100644 --- a/memory.c +++ b/memory.c

Re: [Qemu-devel] [PATCH] scsi: Handle no media case for scsi_get_configuration

On 07/15/2015 02:52 PM, Matthew Rosato wrote: Currently, scsi_get_configuration always returns a current profile (DVD or CD), even when there is actually no media present. By comparison, ide/atapi uses a default profile of 0 (MMC_PROFILE_NONE) for this case and checks for tray_open, so let's

Re: [Qemu-devel] [PATCH] scsi: Handle no media case for scsi_get_configuration

On 07/22/2015 10:18 AM, Paolo Bonzini wrote: On 22/07/2015 16:15, Matthew Rosato wrote: On 07/15/2015 02:52 PM, Matthew Rosato wrote: Currently, scsi_get_configuration always returns a current profile (DVD or CD), even when there is actually no media present. By comparison, ide/atapi uses

[Qemu-devel] [PATCH] scsi: Handle no media case for scsi_get_configuration

seeing with Fedora 22 guests where systemd cdrom_id fails to unmount after a QEMU-initiated eject against a scsi cdrom device because it believes the media is still present (but unreadable). Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com --- hw/scsi/scsi-disk.c | 16 +++- 1

Re: [Qemu-devel] [PATCH 0/4] s390: Allow hotplug of s390 CPUs

On 11/09/2015 10:55 AM, Christian Borntraeger wrote: > Am 09.11.2015 um 16:37 schrieb Christian Borntraeger: >> Am 09.11.2015 um 16:35 schrieb Christian Borntraeger: >>> Am 09.11.2015 um 16:28 schrieb Andreas Färber: >>>> Hi, >>>> >>

[Qemu-devel] [PATCH 4/4] s390x/cpu: Allow hotplug of CPUs

Implement cpu hotplug routine and add the machine hook. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio-ccw.c | 1 + target-s390x/cpu.c

[Qemu-devel] [PATCH 1/4] s390x/cpu: Cleanup init in preparation for hotplug

Ensure a valid cpu_model is set upfront by setting the default value directly into the MachineState when none is specified. This is needed to ensure hotplugged CPUs share the same cpu_model. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbr

[Qemu-devel] [PATCH 3/4] s390x/cpu: Add function to set CPU state

Introduce s390_cpu_set_cpustate, which will set/update the machine/cpu[n] link with the current CPU state. Additionally, maintain an array of state pointers indexed by CPU id for fast lookup during interrupt handling. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Acked-by:

[Qemu-devel] [PATCH 2/4] s390x/cpu: Set initial CPU state in common routine

Both initial and hotplugged CPUs need to set the same initial state. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio.c | 4 target-s390x/cpu.c | 2 ++ 2 files changed, 2 inse

[Qemu-devel] [PATCH 0/4] s390: Allow hotplug of s390 CPUs

based on work previously done by Jason Herne. Matthew Rosato (4): s390x/cpu: Cleanup init in preparation for hotplug s390x/cpu: Set initial CPU state in common routine s390x/cpu: Add function to set CPU state s390x/cpu: Allow hotplug of CPUs hw/s390x/s390-virtio-ccw.c | 3 ++- hw/s390x/

Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device

On 12/10/2015 01:15 AM, Bharata B Rao wrote: > Hi, > > This is an attempt to define a generic CPU device that serves as a > containing device to underlying arch-specific CPU devices. The motivation > for this is to have an arch-neutral way to specify CPUs mainly during > hotplug. > > Instead of

Re: [Qemu-devel] [PATCH v2 1/9] cpus: Reclaim vCPU objects

On 11/19/2015 09:33 PM, Bharata B Rao wrote: > On Thu, Nov 19, 2015 at 10:10:06AM -0500, Matthew Rosato wrote: >> From: Gu Zheng <guz.f...@cn.fujitsu.com> >> >> In order to deal well with the kvm vcpus (which can not be removed without >> any >> protect

[Qemu-devel] [PATCH v2 5/9] s390x/cpu: Move some CPU initialization into realize

In preparation for hotplug, defer some CPU initialization until the device is actually being realized. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- target-s390x/cpu.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/target-s390x/cpu.c b/

[Qemu-devel] [PATCH v2 1/9] cpus: Reclaim vCPU objects

-by: Bharata B Rao <bhar...@linux.vnet.ibm.com> [Explicit CPU_REMOVE() from qemu_kvm/tcg_destroy_vcpu() isn't needed as it is done from cpu_exec_exit()] Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- cpus.c | 41 ++

[Qemu-devel] [PATCH v2 8/9] s390/virtio-ccw: Add hotplug handler and prepare for unplug

Prepare for hotplug and unplug of s390-cpu. In the case of unplug, s390 does not have a safe way of communicating the loss of CPU to a guest, so a full system reset will be performed on the guest. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio-ccw.

[Qemu-devel] [PATCH v2 3/9] s390x/cpu: Cleanup init in preparation for hotplug

Ensure a valid cpu_model is set upfront by setting the default value directly into the MachineState when none is specified. This is needed to ensure hotplugged CPUs share the same cpu_model. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbr

[Qemu-devel] [PATCH v2 9/9] s390x/cpu: Allow hot plug/unplug of CPUs

Allow hotplug of s390-cpu devices via device_add, and unplug via device_del. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- target-s390x/cpu.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c index 4b83a09..a4be7b7

[Qemu-devel] [PATCH v2 4/9] s390x/cpu: Set initial CPU state in common routine

Both initial and hotplugged CPUs need to set the same initial state. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio.c | 4 target-s390x/cpu.c | 2 ++ 2 files changed, 2 inse

[Qemu-devel] [PATCH v2 6/9] s390x/cpu: Add functions to (un)register CPU state

Introduce s390_(un)register_cpustate, which will set the machine/cpu[n] link with the current CPU state. Additionally, maintain an array of state pointers indexed by CPU id for fast lookup during interrupt handling. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- hw/s390

[Qemu-devel] [PATCH v2 2/9] cpus: Add a sync version of cpu_remove()

s when ->plug() handler fails. Signed-off-by: Bharata B Rao <bhar...@linux.vnet.ibm.com> Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> [Call cpu_remove() directly from cpu_remove_sync()] --- cpus.c| 12 include/qom/cpu.h | 8

[Qemu-devel] [PATCH v2 7/9] s390x/cpu: Extra cleanup during CPU finalize

In preparation for unplug, do some additional cleanup work to undo work originally done in cpu_exec_init. This patch is based on work done by Bharata B Rao. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- target-s390x/cpu.c | 14 ++ 1 file changed, 14 inse

[Qemu-devel] [PATCH v2 0/9] s390: Allow hotplug of s390 CPUs

triggers a reset of the guest in order to force recognition. This patch set is based on work previously done by Jason Herne. Bharata B Rao (1): cpus: Add a sync version of cpu_remove() Matthew Rosato (8): cpus: Reclaim vCPU objects s390x/cpu: Cleanup init in preparation for hotplug s390x/

Re: [Qemu-devel] [PATCH v2 2/9] cpus: Add a sync version of cpu_remove()

On 11/19/2015 10:25 AM, Paolo Bonzini wrote: > > > On 19/11/2015 16:10, Matthew Rosato wrote: >> From: Bharata B Rao <bhar...@linux.vnet.ibm.com> >> >> This sync API will be used by the CPU hotplug code to wait for the CPU to >> completely

[Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs

g cpu_exec_exit() exec: Do vmstate unregistration from cpu_exec_exit() cpu: Add a sync version of cpu_remove() Gu Zheng (1): cpu: Reclaim vCPU objects Matthew Rosato (6): s390x/cpu: Cleanup init in preparation for hotplug s390x/cpu: Set initial CPU state in common routine s39

[Qemu-devel] [PATCH v3 01/10] exec: Remove cpu from cpus list during cpu_exec_exit()

From: Bharata B Rao CPUState *cpu gets added to the cpus list during cpu_exec_init(). It should be removed from cpu_exec_exit(). cpu_exec_init() is called from generic CPU::instance_finalize and some archs like PowerPC call it from CPU unrealizefn. So ensure that we

Re: [Qemu-devel] [PATCH v6 05/11] cpu: Reclaim vCPU objects

On 01/08/2016 01:55 AM, Bharata B Rao wrote: > From: Gu Zheng > > In order to deal well with the kvm vcpus (which can not be removed without any > protection), we do not close KVM vcpu fd, just record and mark it as stopped > into a list, so that we can reuse it for the

[Qemu-devel] [PATCH v3 03/10] cpu: Reclaim vCPU objects

From: Gu Zheng In order to deal well with the kvm vcpus (which can not be removed without any protection), we do not close KVM vcpu fd, just record and mark it as stopped into a list, so that we can reuse it for the appending cpu hot-add request if possible. It is also

[Qemu-devel] [PATCH v3 06/10] s390x/cpu: Set initial CPU state in common routine

Both initial and hotplugged CPUs need to set the same initial state. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio.c | 4 target-s390x/cpu.c | 2 ++ 2 files changed, 2 inse

[Qemu-devel] [PATCH v3 04/10] cpu: Add a sync version of cpu_remove()

From: Bharata B Rao This sync API will be used by the CPU hotplug code to wait for the CPU to completely get removed before flagging the failure to the device_add command. Sync version of this call is needed to correctly recover from CPU realization failures when

[Qemu-devel] [PATCH v3 09/10] s390/virtio-ccw: Add hotplug handler and prepare for unplug

Prepare for hotplug and unplug of s390-cpu. In the case of unplug, s390 does not have a safe way of communicating the loss of CPU to a guest, so a full system reset will be performed on the guest. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio-ccw.

[Qemu-devel] [PATCH v3 10/10] s390x/cpu: Allow hot plug/unplug of CPUs

Allow hotplug of s390-cpu devices via device_add, and unplug via device_del. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- target-s390x/cpu.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/target-s390x/cpu.c b/target-s390x/cpu.c index 46b1115..7160f33

[Qemu-devel] [PATCH v3 02/10] exec: Do vmstate unregistration from cpu_exec_exit()

From: Bharata B Rao cpu_exec_init() does vmstate_register and register_savevm for the CPU device. These need to be undone from cpu_exec_exit(). These changes are needed to support CPU hot removal and also to correctly fail hotplug attempts beyond max_cpus.

[Qemu-devel] [PATCH v3 07/10] s390x/cpu: Move some CPU initialization into realize

In preparation for hotplug, defer some CPU initialization until the device is actually being realized. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- target-s390x/cpu.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/target-s390x/cpu.c b/

[Qemu-devel] [PATCH v3 08/10] s390x/cpu: Add functions to (un)register CPU state

Introduce s390_(un)register_cpustate, which will set the machine/cpu[n] link with the current CPU state. Additionally, maintain an array of state pointers indexed by CPU id for fast lookup during interrupt handling. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> --- hw/s390

[Qemu-devel] [PATCH v3 05/10] s390x/cpu: Cleanup init in preparation for hotplug

Ensure a valid cpu_model is set upfront by setting the default value directly into the MachineState when none is specified. This is needed to ensure hotplugged CPUs share the same cpu_model. Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbr

Re: [Qemu-devel] [PATCH v6 1/7] s390x/cpu: Cleanup init in preparation for hotplug

On 02/22/2016 12:46 PM, Andreas Färber wrote: > Am 22.02.2016 um 18:06 schrieb Matthew Rosato: >> Ensure a valid cpu_model is set upfront by setting the >> default value directly into the MachineState when none is >> specified. This is needed to ensure hotplugged CPUs share

Re: [Qemu-devel] [PATCH v6 7/7] s390x/cpu: Allow hotplug of CPUs

On 02/22/2016 12:22 PM, Andreas Färber wrote: > Am 22.02.2016 um 18:06 schrieb Matthew Rosato: >> Implement cpu hotplug routine and add the machine hook. >> >> Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> >> --- &g

  1   2   3   4   5   6   >