> On 6 October 2014 16:08, Cornelia Huck wrote:
> > On Tue, 30 Sep 2014 17:23:47 +0200
> > Jens Freimann wrote:
> >
> >> From: David Hildenbrand
> >>
> >> This patch provides the name of the architecture in the target.xml if
> >> avai
> On 30 September 2014 16:23, Jens Freimann wrote:
> > From: David Hildenbrand
> >
> > 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
> On 6 October 2014 20:14, David Hildenbrand 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:
> > -"
voids calls to
synchronize_rcu() in the kernel.
Reviewed-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
kvm-all.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 1402f4f..b240bf8 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -16
> [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 wrote:
> > From: David Hildenbrand
> >
> > This patch provides the name of the architecture
> 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 Frei
>
> On 10.07.14 15:10, Christian Borntraeger wrote:
> > From: David Hildenbrand
> >
> > 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
>
>
> On 28.07.2014, at 16:16, David Hildenbrand wrote:
>
> >>
> >> On 10.07.14 15:10, Christian Borntraeger wrote:
> >>> From: David Hildenbrand
> >>>
> >>> If a cpu is stopped, it must never be allowed to run and no interrupt m
> >
> > On 28.07.2014, at 16:16, David Hildenbrand wrote:
> >
> > >>
> > >> On 10.07.14 15:10, Christian Borntraeger wrote:
> > >>> From: David Hildenbrand
> > >>>
> > >>> If a cpu is stopped, it must neve
> 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 ex
> > 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
> Add driver functions for geometry and blocksize detection
>
> Signed-off-by: Ekaterina Tumanova
> Reviewed-by: Thomas Huth
> ---
> block.c | 34 ++
> include/block/block.h | 13 +
> include/block/block_int.h | 15 ++
> 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;
>
> In preparation for hotplug, defer some CPU initialization
> until the device is actually being realized.
>
> Signed-off-by: Matthew Rosato
> ---
Reviewed-by: David Hildenbrand
David
> 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 "Recla
> 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 wit
> Introduce s390_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
Acked-by: David Hildenbrand
David
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_id);
> +return;
> +}
> +
> +cpu_s390x_init(machine->cpu_model);
> +}
> +#endif
> +
> +#if !defined(CONFIG_USER_ONLY)
This #if block could be combined with the previous one. But it's not worth
blocking this series so
Acked-by: David Hildenbrand
As we have a clean interface now (cpu-add id=x) most of this series is internal
stuff, so I think this is ready to be picked up :) .
David
gate(errp, l_err);
> +assert(err);
We could also get rid of that assert and remove the return; above (naming the
label "out").
> +error_propagate(errp, err);
> }
>
> static void sclp_memory_init(SCLPDevice *sclp)
Reviewed-by: David Hildenbrand
David
; GB",
> > hw_limit >> 30);
> > -goto error;
> > } else if (ret) {
> > error_setg(&err, "qemu: setting the guest size failed");
> > -goto error;
> > }
> > -return;
> > -error:
&g
> > #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 (i
> 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 branch
> > > 'remotes/kraxel/tags/pull-input-20151020
> 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 c
> 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
law
-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
David
>
> 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_
> 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
> s3
> 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
> s3
> > 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 prop
> 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(+), 3 deletions(-)
>
> diff --git a/target-s390x/c
> 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 +++
> target-s390x/cpu.c
> 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 +++
> target-s390x/cpu.c
> Implement cpu hotplug routine and add the machine hook.
>
> Signed-off-by: Matthew Rosato
Reviewed-by: David Hildenbrand
> ---
> hw/s390x/s390-virtio-ccw.c | 13 +
> target-s390x/cpu.c | 7 +++
> 2 files changed, 20 insertions(+)
>
>
> >> +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, &value, errp);
> >> +}
> >> +
> >> +
> In preparation for hotplug, defer some CPU initialization
> until the device is actually being realized, including
> cpu_exec_init.
>
> Signed-off-by: Matthew Rosato
Looks good to me!
Reviewed-by: David Hildenbrand
David
> Implement cpu hotplug routine and add the machine hook.
>
> Signed-off-by: Matthew Rosato
> Reviewed-by: David Hildenbrand
> ---
> hw/s390x/s390-virtio-ccw.c | 13 +
> target-s390x/cpu.c | 7 +++
> 2 files changed, 20 insertions(+)
>
&
> 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
> +-
> target-s390x/cpu.h | 2 ++
> target-s3
> 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 insertions(+), 6 deletions(-)
> 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
Reviewed-by: David Hildenbrand
David
> > cpu_exec_init(cs, &err);
> > 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 t
> On Fri, Mar 04, 2016 at 12:07:28PM +0100, David Hildenbrand wrote:
> >
> > > > cpu_exec_init(cs, &err);
> > > > if (err != NULL) {
> > > > error_propagate(errp, err);
> > > > return;
>
> 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
Reviewed-by: David Hildenbrand
> ---
> hw/s390x/s390-virtio.c | 11 +
> > 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
> Check for and propogate errors during s390 cpu creation.
>
> Signed-off-by: Matthew Rosato
Looks good to me.
Reviewed-by: David Hildenbrand
David
> 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 acceler
f CPU
> properties that are preventing the CPU model from running in the
> current host.
>
> Cc: David Hildenbrand
> Cc: Michael Mueller
> Cc: Christian Borntraeger
> Cc: Cornelia Huck
> Cc: Jiri Denemark
> Cc: libvir-l...@redhat.com
> Signed-off-by: Eduardo Habkos
> 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
> > > >
> > > > 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 runnable=
> > 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)
> 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 idea
> 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
> > 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 t
> 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
> 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
> 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 fal
> 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.
> 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 of a dictionary
>
Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu_features.c | 44 +++-
target-s390x/cpu_features.h | 23 +++
2 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/target-s390x/cpu_features.c b/target-s390x/cpu_features.c
on"
commands are changed to list all CPU subclasses automatically.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/s390-virtio.c | 6 +-
target-s390x/Makefile.objs | 2 +-
target-s390x/cpu-qom.h | 3 +
target-s390x/cpu.c | 33 +++--
nd when suggesting 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
"cpum
ise).
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu_models.c | 154 ++
1 file changed, 154 insertions(+)
diff --git a/target-s390x/cpu_models.c b/target-s390x/cpu_models.c
index 7e3f544..e7bcea9 100644
--- a/target-s390x/cpu
. Flexible models (e.g. z13): Models that can change between QEMU versions
and will be extended over time as we implement further features that
are already part of such a model in real hardware of certain
configurations.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target
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
Signed-off-by: David Hildenbrand
---
target-s390x/gen-features.c | 80
The mha is provided in the CPU model, so get any CPU and extract the value.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 1 +
include/hw/s390x/sclp.h | 3 ++-
target-s390x/cpu_models.c | 14 ++
target-s390x/cpu_models.h | 1 +
4
Mueller
Signed-off-by: David Hildenbrand
[reworked to include non-stfle features, added definitions]
---
target-s390x/Makefile.objs | 2 +-
target-s390x/cpu_features.c | 334
target-s390x/cpu_features.h | 279
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
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 22 --
1 file changed, 12 in
ver 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
Signed-off-by: David Hildenbrand
---
i
hmfai is provided on CPU models >= z196. Let's propagate it properly.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 1 +
include/hw/s390x/sclp.h | 3 ++-
target-s390x/cpu_models.c | 14 ++
target-s390x/cpu_models.h | 1 +
If we have a lowest ibc, we can indicate the ibc to the guest.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 2 ++
include/hw/s390x/sclp.h | 3 ++-
target-s390x/cpu_models.c | 21 +
target-s390x/cpu_models.h | 12
We have three different blocks in the SCLP read-SCP information response
that indicate sclp features. Let's prepare propagation.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
hw/s390x/sclp.c | 9 +
target-s390x/cpu_models.c | 14 ++
target-
migration safe.
Max features: All supported features that are theoretically allowed for a
CPU model. Exceeding these features could otherwise produce problems with
IBC (instruction blocking controls) in KVM.
Acked-by: Cornelia Huck
Signed-off-by: Michael Mueller
Signed-off-by: David Hildenbran
Let's implement that interface by reusing our conversion code and
lookup code for cpu definitions.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu_models.c | 61 +++
1 file changed, 61 insertions(+)
diff --git a/t
ation from QEMU versions without the CPU model will still work.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu_models.c | 24
target-s390x/cpu_models.h | 2 ++
target-s390x/machine.c| 14 ++
3 files changed, 28 inserti
same 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
Signed-off-by: David Hildenbrand
---
include/sys
Update linux headers to include the new cpu model attributes
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
linux-headers/asm-s390/kvm.h | 40
1 file changed, 40 insertions(+)
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm
le ri.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
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
+++ b/target-s390x/kvm.c
@@ -2440,6 +2440,10 @@ stati
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
Signed-off-by: David Hildenbrand
---
target-s390x/cpu.h| 1 +
target-s390x/cpu_models.c | 26 ++
m 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
Signed-off-by: David Hildenbrand
---
include/sysemu/arch_init.h| 4
qapi-schema.json | 44 +
Let's implement our two hooks so we can support CPU models.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu_models.c | 75 +++-
target-s390x/cpu_models.h | 50
target-s390x/kvm.c| 295
ides.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/gen-features.c | 1 +
target-s390x/kvm.c | 47 ++---
2 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/target-s390x/gen-features.c b/target-s390x/gen-f
Let's implement that interface by reusing our convertion code
implemented for expansion.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu_models.c | 84 +++
1 file changed, 84 insertions(+)
diff --git a/target-
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
Signed-off-by: David Hildenbrand
---
hw/s390x/s390-virtio-ccw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/s390x/s390
model, because that could collide with the IBC in KVM.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu.c| 1 +
target-s390x/cpu.h| 1 +
target-s390x/cpu_models.c | 149 ++
3 files changed, 151 inse
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
Signed-off-by: David Hildenbrand
---
include/
Let's expose the description and migration safety, as class properties,
this can be helpful in the future.
Acked-by: Cornelia Huck
Signed-off-by: David Hildenbrand
---
target-s390x/cpu.c| 1 +
target-s390x/cpu.h| 1 +
target-s390x/cpu_models.c | 18 ++
3
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
Signed-off-by: David Hildenbrand
---
target-s390x
> (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 real
> 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
> 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 reporte
> 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
> 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 wro
> 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
>
> > > > 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 ex
> 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 f
> 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 the
> 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
> > > &g
> 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
allowing the running ones
to finish.
Signed-off-by: David Hildenbrand
You might want to drop that and instead mention something like "This
patch is based on a protoype patch by David Hildenbrand".
Signed-off-by: Emanuele Giuseppe Esposito
---
accel/kvm/kvm-all.c | 7 ++
On 29.11.22 00:48, Ilya Leoshkevich wrote:
Add a simple test to prevent regressions.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/s390x/Makefile.target | 4 ++
tests/tcg/s390x/cdsg.c | 73 +
2 files changed, 77 insertions(+)
create mode 100644 te
On 29.11.22 12:21, Kirill A. Shutemov wrote:
On Mon, Nov 28, 2022 at 06:06:32PM -0600, Michael Roth wrote:
On Tue, Oct 25, 2022 at 11:13:37PM +0800, Chao Peng wrote:
From: "Kirill A. Shutemov"
+static struct file *restrictedmem_file_create(struct file *memfd)
+{
+ struct restricted
1 - 100 of 7081 matches
Mail list logo
