Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking has_work

On 10.07.14 15:10, Christian Borntraeger wrote: From: David Hildenbrand d...@linux.vnet.ibm.com If a cpu is stopped, it must never be allowed to run and no interrupt may wake it up. A cpu also has to be unhalted if it is halted and has work to do - this scenario wasn't hit in kvm

Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking has_work

On 28.07.2014, at 16:16, David Hildenbrand d...@linux.vnet.ibm.com wrote: On 10.07.14 15:10, Christian Borntraeger wrote: From: David Hildenbrand d...@linux.vnet.ibm.com If a cpu is stopped, it must never be allowed to run and no interrupt may wake it up. A cpu also has

Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking has_work

Il 28/07/2014 17:03, David Hildenbrand ha scritto: Well the difference is, that a STOPPED vcpu can be woken up by non-interrupt like things (SIGP START) AND a special interrupt (SIGP RESTART - which is like a SIPI++ as it performs a psw exchange - NMI). So we basically have two paths

Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking has_work

We have - wait (wait bit in PSW) - disabled wait (wait bit and interrupt fencing in PSW) - STOPPED (not related to PSW, state change usually handled via service processor or hypervisor) I think we have to differentiate between KVM/TCG. On KVM we always do in kernel halt and qemu

Re: [Qemu-devel] [PATCH 4/4] s390x/kvm: hw debugging support via guest PER facility

On 30/05/14 11:01, Alexander Graf wrote: On 30.05.14 10:57, Christian Borntraeger wrote: On 30/05/14 10:32, Alexander Graf wrote: +case KVM_HW_BP: +if (find_hw_breakpoint(arch_info-addr, -1, arch_info-type)) { +ret = EXCP_DEBUG; +} +

Re: [Qemu-devel] [PATCH/RFC 0/5] s390x/kvm: track the logical cpu state in QEMU and propagate it to kvm

This is the qemu part of kernel series Let user space control the cpu states Christian Borntraeger (1): update linux headers with with cpustate changes David Hildenbrand (4): s390x/kvm: introduce proper states for s390 cpus s390x/kvm: proper use of the cpu states OPERATING

Re: [Qemu-devel] [PATCH/RFC 0/5] s390x/kvm: track the logical cpu state in QEMU and propagate it to kvm

This is the qemu part of kernel series Let user space control the cpu states Christian Borntraeger (1): update linux headers with with cpustate changes David Hildenbrand (4): s390x/kvm: introduce proper states for s390 cpus s390x/kvm: proper use of the cpu states OPERATING

Re: [Qemu-devel] [PATCH/RFC 0/5] s390x/kvm: track the logical cpu state in QEMU and propagate it to kvm

This is the qemu part of kernel series Let user space control the cpu states Christian Borntraeger (1): update linux headers with with cpustate changes David Hildenbrand (4): s390x/kvm: introduce proper states for s390 cpus s390x/kvm: proper use of the cpu states

Re: [Qemu-devel] [PATCH 5/5] gdb: provide the name of the architecture in the target.xml

[ccing Andreas in case he wants to review the QOM aspects of this, though they're fairly straightforward I think.] On 29 August 2014 14:52, Jens Freimann jf...@linux.vnet.ibm.com wrote: From: David Hildenbrand d...@linux.vnet.ibm.com This patch provides the name of the architecture

Re: [Qemu-devel] [PATCH 5/5] gdb: provide the name of the architecture in the target.xml

On Wed, Sep 03, 2014 at 11:37:24AM +0200, David Hildenbrand wrote: [ccing Andreas in case he wants to review the QOM aspects of this, though they're fairly straightforward I think.] On 29 August 2014 14:52, Jens Freimann jf...@linux.vnet.ibm.com wrote: From: David Hildenbrand d

Re: [Qemu-devel] [PATCH] gdb: provide the name of the architecture in the target.xml

On 6 October 2014 16:08, Cornelia Huck cornelia.h...@de.ibm.com wrote: On Tue, 30 Sep 2014 17:23:47 +0200 Jens Freimann jf...@linux.vnet.ibm.com wrote: From: David Hildenbrand d...@linux.vnet.ibm.com This patch provides the name of the architecture in the target.xml if available

Re: [Qemu-devel] [PATCH] gdb: provide the name of the architecture in the target.xml

On 30 September 2014 16:23, Jens Freimann jf...@linux.vnet.ibm.com wrote: From: David Hildenbrand d...@linux.vnet.ibm.com This patch provides the name of the architecture in the target.xml if available. This allows the remote gdb to detect the target architecture on its own - so

Re: [Qemu-devel] [PATCH] gdb: provide the name of the architecture in the target.xml

On 6 October 2014 20:14, David Hildenbrand d...@linux.vnet.ibm.com wrote: actually the questions were addressed in the last review. Haven't received any answer from you to my reply. Maybe some mails got lost in the system. 32bit arm: -On my way through the possible architecture names

Re: [Qemu-devel] [PATCH v4 1/5] block: add bdrv functions for geometry and blocksize

Add driver functions for geometry and blocksize detection Signed-off-by: Ekaterina Tumanova tuman...@linux.vnet.ibm.com Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com --- block.c | 34 ++ include/block/block.h | 13 +

Re: [Qemu-devel] [PATCH for-2.5 7/8] s390x: Migrate guest storage keys (initial memory only)

So if I've got this code right, you send here a header that announces a packet with all pages ... +while (handled_count total_count) { +cur_count = MIN(total_count - handled_count, S390_SKEYS_BUFFER_SIZE); + +ret = skeyclass-get_skeys(ss, cur_gfn, cur_count,

Re: [Qemu-devel] [PULL 0/9] Next set of s390x patches

> On Tue, 20 Oct 2015 16:35:44 +0100 > Peter Maydell wrote: > > > On 20 October 2015 at 16:00, Cornelia Huck wrote: > > > The following changes since commit > > > ee9dfed242610ecb91418270fd46b875ed56e201: > > > > > > Merge remote-tracking

Re: [Qemu-devel] [PATCH 3/4] virtio-ccw: feature bits > 31 handling

ore buggy. > */ > -if (dev->revision <= 0) { > -features.features &= ~(1 << (VIRTIO_F_VERSION_1 - 32)); > - } > virtio_set_features(vdev, > (vdev->guest_features & > 0xULL) | > ((uint64_t)features.features << 32)); Looks sane to me! Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> David

Re: [Qemu-devel] [PATCH 5/7] qdev: Protect device-list-properties against broken devices

> No knowledge should be required for object_new(). Classes' instance_init > functions should have no side-effects outside the object itself. While this should theoretically be true, I can guarantee to you that this is not the case for all devices :) (especially as there are too many unwritten

Re: [Qemu-devel] [PATCH 5/7] qdev: Protect device-list-properties against broken devices

> Am 18.09.2015 um 14:00 schrieb Markus Armbruster: > > Several devices don't survive object_unref(object_new(T)): they crash > > or hang during cleanup, or they leave dangling pointers behind. > > > > This breaks at least device-list-properties, because > > qmp_device_list_properties() needs to

Re: [Qemu-devel] [PATCH 4/4] hw/s390x: Rename local variables Error *l_err to just err

GB", > > hw_limit >> 30); > > -goto error; > > } else if (ret) { > > error_setg(, "qemu: setting the guest size failed"); > > -goto error; > > } > > -return; > > -error: > > -

Re: [Qemu-devel] [PATCH 4/4] hw/s390x: Rename local variables Error *l_err to just err

gt; -error_setg(_err, "qemu: setting the guest size failed"); > +error_setg(, "qemu: setting the guest size failed"); > goto error; > } > return; > error: > -assert(l_err); > -error_propagate(errp, l_err); > +assert(err); We cou

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

> Current CLI option -cpu cpux,features serves as template > for all created cpus of type: cpux. However QEMU parses > "features" every time it creates a cpu instance and applies > them to it while doing parsing. > > That doesn't work well with -device/device_add infrastructure > as it has no

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

> I assume Igor explained it, already, and his suggestion sounds OK > to you. But I will answer your questions to confirm that this is > really the case: Yes, this all sounds good to me, thanks for the additional explanation! [...] > > > > > d) has to work for us. Otherwise we will have to

Re: [Qemu-devel] [libvirt] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions

> It is not exactly a special case (it is a read-only property like > any other), but it's worth mentioning. I will change it to: > > # If the QOM property is read-only, that means there's no known > # way to make the CPU model run in the current host. If > # absolutely no extra information will

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

> On Thu, Jun 02, 2016 at 22:44:49 +0200, David Hildenbrand wrote: > > > Current CLI option -cpu cpux,features serves as template > > > for all created cpus of type: cpux. However QEMU parses > > > "features" every time it creates a cpu instance and appl

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

> > e.g. in terms of s390x: z13 includes both vx and tx > > -cpu z13,vx=off,tx=off > Above -cpu template will be translated into a corresponding > global properties template: > > -global z13-s390-cpu.vx=off -global z13-s390-cpu.tx=off This description makes it much clearer how you expect -cpu

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

> On Thu, Jun 02, 2016 at 10:44:49PM +0200, David Hildenbrand wrote: > > > Current CLI option -cpu cpux,features serves as template > > > for all created cpus of type: cpux. However QEMU parses > > > "features" every time it creates a cpu instance and appl

Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

> On Tue, Jun 21, 2016 at 13:44:31 -0300, Eduardo Habkost wrote: > > (CCing libvirt people) > > > > On Tue, Jun 21, 2016 at 03:02:05PM +0200, David Hildenbrand wrote: > > > This is our second attempt to implement CPU models for s390x. We realized > > > tha

Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

> On Tue, Jun 21, 2016 at 17:33:09 -0300, Eduardo Habkost wrote: > > On Tue, Jun 21, 2016 at 07:01:44PM +0200, David Hildenbrand wrote: > > > > (CCing libvirt people) > > > > > > > > On Tue, Jun 21, 2016 at 03:02:05PM +0200, David Hildenbrand

Re: [Qemu-devel] [RFC 06/28] s390x/cpumodel: introduce CPU feature group definitions

> On 21.06.2016 15:02, David Hildenbrand wrote: > > Let's use the generated groups to create feature group representations for > > the user. These groups can later be used to enable/disable multiple > > features in one shot and will be used to reduce the amount of reported >

Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

> On Wed, Jun 22, 2016 at 09:34:49 +0200, David Hildenbrand wrote: > > I think the coffee didn't do its work already :) . I wanted to write that > > we can > > _with_ this additional query. Meaning the involved overhead would be ok - > > in my > > opinion for

Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

> > > > 2) Requiring a running QEMU instance to run > > > >query-cpu-model-comparison > > > > > > > > With my previous query-host-cpu proposal, the task of comparing > > > > the configuration requested by the user with host capabilities > > > > can be done directly by libvirt. This way, no

Re: [Qemu-devel] [libvirt] [RFC 00/28] s390x CPU models: exposing features

> On Tue, Jun 21, 2016 at 18:22:30 -0300, Eduardo Habkost wrote: > > On Tue, Jun 21, 2016 at 11:09:49PM +0200, Jiri Denemark wrote: > > [...] > > > > 1) "query-cpu-model-expansion model=host" vs "query-host-cpu": > > > > > > > > I still don't think we want to set in stone that "the result the >

[Qemu-devel] [RFC 10/28] s390x/cpumodel: let the CPU model handle feature checks

ation from QEMU versions without the CPU model will still work. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu_models.c | 24 target-s390x/cpu_models.h | 2 ++ target-s

[Qemu-devel] [RFC 04/28] s390x/cpumodel: generate CPU feature lists for CPU models

.com> Signed-off-by: Michael Mueller <m...@linux.vnet.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> [generate base, default and models. renaming and cleanup] --- Makefile.target | 2 +- rules.mak | 1 + target-s390x/Make

[Qemu-devel] [RFC 28/28] s390x/cpumodel: implement QMP interface "query-cpu-model-baseline"

Let's implement that interface by reusing our conversion code and lookup code for cpu definitions. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu_models.c | 61 ++

[Qemu-devel] [RFC 14/28] s390x/sclp: indicate sclp features

We have three different blocks in the SCLP read-SCP information response that indicate sclp features. Let's prepare propagation. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/sclp.c | 9 +

[Qemu-devel] [RFC 18/28] update linux headers (CPU model)

Update linux headers to include the new cpu model attributes Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- linux-headers/asm-s390/kvm.h | 40 1 file changed, 40 insertions(+)

[Qemu-devel] [RFC 21/28] s390x/kvm: disable host model for existing compat machines

. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/kvm.c | 4 1 file changed, 4 insertions(+) diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c index 6002cf9..a4f5762 100644 --- a/target-s390x/kvm.c

[Qemu-devel] [RFC 20/28] s390x/kvm: implement CPU model support

Let's implement our two hooks so we can support CPU models. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu_models.c | 75 +++- target-s390x/cpu_models.h | 50 target-s390x/kvm.c

[Qemu-devel] [RFC 25/28] qmp: add QMP interface "query-cpu-model-baseline"

possible model, e.g. by maximizing features. The host CPU model has the same semantics as for "query-cpu-model-expansion". Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- include/sysemu/arch_ini

[Qemu-devel] [RFC 09/28] s390x/cpumodel: expose features and feature groups as properties

l, because that could collide with the IBC in KVM. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu.c| 1 + target-s390x/cpu.h| 1 + target-s3

[Qemu-devel] [RFC 08/28] s390x/cpumodel: store the CPU model in the CPU instance

KVM later on. The other models are all initialized from their definitions. Only the "host" model can have a cpu->model == NULL. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu

[Qemu-devel] [RFC 22/28] s390x/kvm: let the CPU model control CMM(A)

-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/gen-features.c | 1 + target-s390x/kvm.c | 47 ++--- 2 files changed, 37 insertions(+), 11 deletions(-) diff --git a/

[Qemu-devel] [RFC 15/28] s390x/sclp: propagate the ibc val(lowest and unblocked ibc)

If we have a lowest ibc, we can indicate the ibc to the guest. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/sclp.c | 2 ++ include/hw/s390x/sclp.h | 3 ++- target-s390x/cpu_m

[Qemu-devel] [RFC 23/28] qmp: add QMP interface "query-cpu-model-expansion"

guest ABI on other QEMU versions. This interface is very helpful when CPU models are to be updated between QEMU versions. The updated model can then simply be expanded to a migration safe representation. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: Davi

[Qemu-devel] [RFC 02/28] s390x/cpumodel: expose CPU class properties

Let's expose the description and migration safety, as class properties, this can be helpful in the future. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu.c| 1 + target-s390x/cpu.h|

[Qemu-devel] [RFC 06/28] s390x/cpumodel: introduce CPU feature group definitions

<cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu_features.c | 44 +++- target-s390x/cpu_features.h | 23 +++ 2 files changed, 66 insertions(+), 1 deletion(-) diff --git a/

[Qemu-devel] [RFC 01/28] s390x/cpumodel: "host" and "qemu" as CPU subclasses

on" commands are changed to list all CPU subclasses automatically. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio.c | 6 +- target-s390x/Makefile.objs | 2 +- target-s390x/cpu-qom.h |

[Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

ggesting some major design changes. The header update will be replaced by a kvm-next header update as soon as the VSIE patches are upstream. The major KVM interface changes are already part of kvm-next. The current state is available on git://github.com/cohuck/qemu on branch "cpumodel-s390x

[Qemu-devel] [RFC 11/28] s390x/cpumodel: check and apply the CPU model

e). Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu_models.c | 154 ++ 1 file changed, 154 insertions(+) diff --git a/target-s390x/cpu_models.c b/target-s390x/cpu_

[Qemu-devel] [RFC 13/28] s390x/sclp: introduce sclp feature blocks

The sclp "read cpu info" and "read scp info" commands can include features for the cpu info and configuration characteristics (extended), decribing some advanced features available in the configuration. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-of

[Qemu-devel] [RFC 26/28] s390x/cpumodel: implement QMP interface "query-cpu-model-expansion"

In order to expand CPU models, we create temporary cpus that handle the feature/group parsing. When converting the data structure back, we always fall back to the base cpu model, which is by definition migration safe. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by:

Re: [Qemu-devel] [PATCH 0/3] qmp: query-host-cpu command

> On Tue, Jun 21, 2016 at 08:20:40AM +0200, David Hildenbrand wrote: > > > Add QMP command to allow management software to query for > > > CPU information for the running host. > > > > > > The data returned by the command is in the form

[Qemu-devel] [RFC 24/28] qmp: add QMP interface "query-cpu-model-comparison"

a superset of modelB or if both are incompatible, one can try to create a compatible one by "baselining" both models (follow up patch). The host CPU model has the same semantics as for "query-cpu-model-expansion". Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-of

[Qemu-devel] [RFC 17/28] s390x/sclp: propagate hmfai

hmfai is provided on CPU models >= z196. Let's propagate it properly. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/sclp.c | 1 + include/hw/s390x/sclp.h | 3 ++- target-s390x/cp

[Qemu-devel] [RFC 12/28] s390x/sclp: factor out preparation of cpu entries

Let's factor out the common code of "read cpu info" and "read scp info". This will make the introduction of new cpu entry fields easier. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.c

[Qemu-devel] [RFC 27/28] s390x/cpumodel: implement QMP interface "query-cpu-model-comparison"

Let's implement that interface by reusing our convertion code implemented for expansion. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu_models.c | 84 +++

[Qemu-devel] [RFC 03/28] s390x/cpumodel: introduce CPU features

ornelia.h...@de.ibm.com> Signed-off-by: Michael Mueller <m...@linux.vnet.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> [reworked to include non-stfle features, added definitions] --- target-s390x/Makefile.objs | 2 +- target-s3

[Qemu-devel] [RFC 16/28] s390x/sclp: propagate the mha via sclp

The mha is provided in the CPU model, so get any CPU and extract the value. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/sclp.c | 1 + include/hw/s390x/sclp.h | 3 ++- target-s390x/cpu_m

[Qemu-devel] [RFC 07/28] s390x/cpumodel: register defined CPU models as subclasses

ed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu-qom.h| 2 + target-s390x/cpu_models.c | 111 ++ target-s390x/cpu_models.h | 36 +++ 3 files changed, 149 insertions(+) create mode 100644 target-s390x/cpu_mo

[Qemu-devel] [RFC 05/28] s390x/cpumodel: generate CPU feature group lists

of them are in place. Groups only contain features that were introduced in one shot, not just random features. Therefore, groups can never change. This is an important property regarding migration. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbr

[Qemu-devel] [RFC 19/28] s390x/kvm: allow runtime-instrumentation for "none" machine

To be able to query the correct host model for the "none" machine, let's allow runtime-instrumentation for that machine. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/s390-virtio-ccw.c | 5 ++

Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

> (CCing libvirt people) > > On Tue, Jun 21, 2016 at 03:02:05PM +0200, David Hildenbrand wrote: > > This is our second attempt to implement CPU models for s390x. We realized > > that we also want to have features exposed via the CPU model. While doing > > that we re

Re: [Qemu-devel] [PATCH 0/3] qmp: query-host-cpu command

> On Tue, Jun 21, 2016 at 02:52:54PM +0200, David Hildenbrand wrote: > > > On Tue, Jun 21, 2016 at 08:20:40AM +0200, David Hildenbrand wrote: > > > > > Add QMP command to allow management software to query for > > > > > CPU information for the running ho

Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

> On Wed, Jun 22, 2016 at 09:54:51 +0200, David Hildenbrand wrote: > > > On Wed, Jun 22, 2016 at 09:34:49 +0200, David Hildenbrand wrote: > > > > I think the coffee didn't do its work already :) . I wanted to write > > > > that we can > > > > _w

Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

> Question: KVM supports x2apic (and enables it by default) on any > host CPU, because it is all emulated by KVM. Should "host-model" > include x2apic on all hosts, or only when the host CPU has it? > ("-cpu host" does include it). > > Including x2apic sounds more useful, but it doesn't match

Re: [Qemu-devel] [PATCH 0/3] qmp: query-host-cpu command

> Add QMP command to allow management software to query for > CPU information for the running host. > > The data returned by the command is in the form of a dictionary > of QOM properties. > > This series depends on the "Add runnability info to > query-cpu-definitions" series I sent 2 weeks ago.

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

> Changes from v2->v3: > > * Call cpu_remove_sync rather than cpu_remove(). > * Pull latest version of patches from pseries set (v6). Trivial change to > "Reclaim VCPU objects" to fix checkpatch error. > * Add object_unparent during s390_cpu_release to accomodate changes in > Patch 4

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

> Am 10.02.2016 um 16:28 schrieb David Hildenbrand: > > For x86, cpu models are realized by making x86_64-cpu an abstract class and > > creating loads of new classes, e.g. host-x86_64-cpu or haswell-x86_64-cpu. > > > > How does 'device_add ' play together with the

Re: [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> > --- Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> David

Re: [Qemu-devel] [PATCH v4 4/5] s390x/cpu: Add functions to register CPU state

.vnet.ibm.com> Acked-by: David Hildenbrand <d...@linux.vnet.ibm.com> David

Re: [Qemu-devel] [PATCH v4 5/5] s390x/cpu: Allow hotplug of CPUs

; + ", max allowed: %d", id, max_cpus - 1); > +return; > +} > + > +if (id != next_cpu_id) { > +error_setg(errp, "Unable to add CPU: %" PRIi64 > + ", The next available id is %d", id, next_cpu_i

Re: [Qemu-devel] [PATCH v4 5/5] s390x/cpu: Allow hotplug of CPUs

> > #if !defined(CONFIG_USER_ONLY) > > +void s390_hot_add_cpu(const int64_t id, Error **errp) > > +{ > to make it future-proof wrt migration it could be better to > enforce here that 'id' grows in +1 steps so user > won't be able create cpus with gaps. That should be already covered by: if

Re: [Qemu-devel] [PATCH v8 6/7] s390x/cpu: Add error handling to cpu creation

> > After all the discussions about > > -device-add s390-cpu,id=XX > > > > As substitute/addition in the future for hotplug it is the straightforward > > approach to allow setting the id as property. Nobody knows what crazy new > > hotplug method we will come up with. But doing it the device way

Re: [Qemu-devel] [PATCH v9 6/7] s390x/cpu: Add error handling to cpu creation

> Check for and propogate errors during s390 cpu creation. > > Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Looks good to me. Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> David

Re: [Qemu-devel] [PATCH v8 6/7] s390x/cpu: Add error handling to cpu creation

> On Fri, Mar 04, 2016 at 12:07:28PM +0100, David Hildenbrand wrote: > > > > > > cpu_exec_init(cs, ); > > > > if (err != NULL) { > > > > error_propagate(errp, err); > > > > return; > &g

Re: [Qemu-devel] [PATCH v8 3/7] s390x/cpu: Get rid of side effects when creating a vcpu

> In preparation for hotplug, defer some CPU initialization > until the device is actually being realized, including > cpu_exec_init. > > Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Looks good to me! Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> David

Re: [Qemu-devel] [PATCH v8 4/7] s390x/cpu: Tolerate max_cpus

> Once hotplug is enabled, interrupts may come in for CPUs > with an address > smp_cpus. Allocate for this and allow > search routines to look beyond smp_cpus. > > Signed-off-by: Matthew Rosato > --- > hw/s390x/s390-virtio.c | 13 +++-- > 1 file changed, 7

Re: [Qemu-devel] [PATCH v8 6/7] s390x/cpu: Add error handling to cpu creation

> Check for and propogate errors during s390 cpu creation. > > Signed-off-by: Matthew Rosato > --- > hw/s390x/s390-virtio.c | 2 +- > target-s390x/cpu-qom.h | 1 + > target-s390x/cpu.c | 56 > +- >

Re: [Qemu-devel] [PATCH v8 7/7] 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 | 13 + > target-s390x/cpu.c

Re: [Qemu-devel] [PATCH v8 5/7] s390x/cpu: Add CPU property links

> Link each CPUState as property machine/cpu[n] during initialization. > Add a hotplug handler to s390-virtio-ccw machine and set the > state during plug. > > Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com> David

Re: [Qemu-devel] [PATCH v8 6/7] s390x/cpu: Add error handling to cpu creation

> > cpu_exec_init(cs, ); > > if (err != NULL) { > > error_propagate(errp, err); > > return; > > } > > +scc->next_cpu_id = cs->cpu_index + 1; > > It appears that scc->next_cpu_id (and hence cpu->id) is some sort of arch_id > for you. If it is just going to

Re: [Qemu-devel] [PATCH v7 5/6] s390x/cpu: Add error handling to cpu creation

> Check for and propogate errors during s390 cpu creation. > > Signed-off-by: Matthew Rosato > --- > hw/s390x/s390-virtio-ccw.c | 30 + > hw/s390x/s390-virtio.c | 2 +- > hw/s390x/s390-virtio.h | 1 + > target-s390x/cpu-qom.h | 3

Re: [Qemu-devel] [PATCH v7 3/6] 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 > Reviewed-by: Andreas Färber > --- > target-s390x/cpu.c | 9 ++--- > 1 file changed, 6 insertions(+),

Re: [Qemu-devel] [PATCH v7 6/6] 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 | 13 + > target-s390x/cpu.c |

Re: [Qemu-devel] [PATCH v7 5/6] s390x/cpu: Add error handling to cpu creation

> Check for and propogate errors during s390 cpu creation. > > Signed-off-by: Matthew Rosato > --- > hw/s390x/s390-virtio-ccw.c | 30 + > hw/s390x/s390-virtio.c | 2 +- > hw/s390x/s390-virtio.h | 1 + > target-s390x/cpu-qom.h | 3

Re: [Qemu-devel] [PATCH v7 5/6] s390x/cpu: Add error handling to cpu creation

> >> +static void s390_cpu_get_id(Object *obj, Visitor *v, const char *name, > >> +void *opaque, Error **errp) > >> +{ > >> +S390CPU *cpu = S390_CPU(obj); > >> +int64_t value = cpu->id; > >> + > >> +visit_type_int(v, name, , errp); > >> +} > >> + > >>

Re: [Qemu-devel] [PATCH v9 4/7] s390x/cpu: Tolerate max_cpus

> Once hotplug is enabled, interrupts may come in for CPUs > with an address > smp_cpus. Allocate for this and allow > search routines to look beyond smp_cpus. > > Signed-off-by: Matthew Rosato <mjros...@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <d...@linux

Re: [Qemu-devel] [libvirt] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions

> Updated to: > > ## > # @CpuDefinitionInfo: > # > # Virtual CPU definition. > # > # @name: the name of the CPU definition > # @runnable: #optional. whether the CPU model us usable with the > #current machine and accelerator. Omitted if we don't > #know the answer. (since

Re: [Qemu-devel] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions

> > Yes, I think so. However to really make good hints, upper layers would most > > likely need more information about the exact problem with a property - > > maybe something like an enum value per problematic property. > > (UNAVAILABLE_FEATURE, VALUE_TOO_BIG, VALUE_TOO_SMALL, UNSUPPORTED_VALUE)

Re: [Qemu-devel] [PATCH 0/9] Add runnability info to query-cpu-definitions

> This series extends query-cpu-definitions to include two extra > fields: "runnable", and "unavailable-features". > > This will return information based on the current machine and > accelerator only. In the future we may extend these mechanisms to > allow querying other machines and other

Re: [Qemu-devel] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions

f CPU > properties that are preventing the CPU model from running in the > current host. > > Cc: David Hildenbrand <d...@linux.vnet.ibm.com> > Cc: Michael Mueller <m...@linux.vnet.ibm.com> > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Cc: Cornel

Re: [Qemu-devel] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions

> On Mon, May 09, 2016 at 10:54:53AM +0200, David Hildenbrand wrote: > > > Extend query-cpu-definitions schema to allow it to return two new > > > optional fields: "runnable" and "unavailable-features". > > > "runnable" will tell if the

Re: [Qemu-devel] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions

> > > > > > > > Just FYI, on other architectures (e.g. s390x), other conditions (e.g. > > > > cpu > > > > generation) also define if a CPU model is runnable, so the pure > > > > availability of > > > > features does not mean that a cpu model is runnable. > > > > > > > > We could have

[Qemu-devel] [Patch v1 11/29] s390x/cpumodel: let the CPU model handle feature checks

ation from QEMU versions without the CPU model will still work. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu_models.c | 24 target-s390x/cpu_models.h | 2 ++ target-s

[Qemu-devel] [Patch v1 08/29] s390x/cpumodel: register defined CPU models as subclasses

ed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu-qom.h| 2 + target-s390x/cpu_models.c | 113 ++ target-s390x/cpu_models.h | 36 +++ 3 files changed, 151 insertions(+) create mode 100644 target-s390x/cpu_mo

[Qemu-devel] [Patch v1 15/29] s390x/sclp: indicate sclp features

We have three different blocks in the SCLP read-SCP information response that indicate sclp features. Let's prepare propagation. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- hw/s390x/sclp.c | 9 +

[Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features

del-baseline", "arguments":{ "modela":{ "name":"z13.2-base", "props":{ ... } }, "modelb":{ "name":"zEC12.2-base", "props":{ ... }

[Qemu-devel] [Patch v1 09/29] s390x/cpumodel: store the CPU model in the CPU instance

KVM later on. The other models are all initialized from their definitions. Only the "host" model can have a cpu->model == NULL. Acked-by: Cornelia Huck <cornelia.h...@de.ibm.com> Signed-off-by: David Hildenbrand <d...@linux.vnet.ibm.com> --- target-s390x/cpu

  1   2   3   4   5   6   7   8   9   10   >