Re: [Qemu-devel] [Question] why x2apic's set by default without host support(on Nehalem CPU).

2013-07-23 Thread Jiri Denemark
On Tue, Jul 23, 2013 at 10:44:48 +0800, Peter Huang(Peng) wrote: libvirt's host-passthrough uses -cpu host', and it -cpu host enables every feature that can be enabled on the host. From my test results, I found that even when use host-passthrough mode, VM's cpu features are very different

[Qemu-devel] [PATCH] configure: Fix spice probe

2011-01-24 Thread Jiri Denemark
From: Jiri Denemark jiri.denem...@gmail.com Non-existent $pkgconfig instead of $pkg_config was used when configure probes for spice availability. Signed-off-by: Jiri Denemark jdene...@redhat.com --- configure |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [Qemu-devel] [PATCH] configure: Fix spice probe

2011-01-24 Thread Jiri Denemark
On Mon, Jan 24, 2011 at 15:01:27 +0100, Gerd Hoffmann wrote: On 01/24/11 13:20, Jiri Denemark wrote: From: Jiri Denemarkjiri.denem...@gmail.com Non-existent $pkgconfig instead of $pkg_config was used when configure probes for spice availability. What tree you are looking at? It _is_

Re: [Qemu-devel] [PATCH] configure: Fix spice probe

2011-01-24 Thread Jiri Denemark
On Mon, Jan 24, 2011 at 15:17:17 +0100, Jiri Denemark wrote: On Mon, Jan 24, 2011 at 15:01:27 +0100, Gerd Hoffmann wrote: On 01/24/11 13:20, Jiri Denemark wrote: From: Jiri Denemarkjiri.denem...@gmail.com Non-existent $pkgconfig instead of $pkg_config was used when configure probes

[Qemu-devel] [PATCH] Fix CPU topology initialization

2010-01-05 Thread Jiri Denemark
Late initialization of CPU topology in CPUState prevents KVM guests to actually see the topology. Signed-off-by: Jiri Denemark jdene...@redhat.com --- vl.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/vl.c b/vl.c index e881e45..a03d7a6 100644 --- a/vl.c +++ b

Re: [Qemu-devel] libvirt doesn't work with qemu 1.0

2011-12-02 Thread Jiri Denemark
On Fri, Dec 02, 2011 at 08:50:11 -0600, Anthony Liguori wrote: On 12/02/2011 08:21 AM, Gerd Hoffmann wrote: Hi, $subject says all. The error message is: error: internal error cannot parse /home/kraxel/bin/qemu-default version number in 'QEMU emulator version 1.0, Copyright (c)

[Qemu-devel] Modern CPU models cannot be used with libvirt

2011-12-15 Thread Jiri Denemark
Hi, Recently I realized that all modern CPU models defined in /etc/qemu/target-x86_64.conf are useless when qemu is used through libvirt. That's because we start qemu with -nodefconfig which results in qemu ignoring that file with CPU model definitions. We have a very good reason for using

Re: [Qemu-devel] Modern CPU models cannot be used with libvirt

2011-12-15 Thread Jiri Denemark
On Thu, Dec 15, 2011 at 08:58:55 -0600, Anthony Liguori wrote: Pass '-readconfig /etc/qemu/target-x86_64.conf' to pick up those models and if you are absolutely insistent on not giving the user any ability to change things on their own, cp the file from qemu.git into libvirt.git and

Re: [Qemu-devel] QMP: RFC: I/O error info query-stop-reason

2011-06-02 Thread Jiri Denemark
On Thu, Jun 02, 2011 at 08:08:35 -0500, Anthony Liguori wrote: On 06/02/2011 04:06 AM, Daniel P. Berrange wrote: B. query-stop-reason I also have a simple solution for item 2. The vm_stop() accepts a reason argument, so we could store it somewhere and return it as a

Re: [Qemu-devel] [patch 6/7] QEMU live block copy (update)

2011-06-07 Thread Jiri Denemark
On Mon, Jun 06, 2011 at 14:03:44 -0300, Marcelo Tosatti wrote: ... SQMP +query-block-copy +- + +Live block copy status. + +Each block copy instance information is stored in a json-object and the returned +value is a json-array of all instances. + +Each json-object contains

Re: [Qemu-devel] [patch 4/4] QEMU live block copy

2011-06-16 Thread Jiri Denemark
On Wed, Jun 15, 2011 at 14:14:07 -0300, Marcelo Tosatti wrote: Index: qemu-block-copy/qmp-commands.hx === --- qemu-block-copy.orig/qmp-commands.hx +++ qemu-block-copy/qmp-commands.hx ... SQMP +query-block-copy +-

[Qemu-devel] [PATCH STABLE] build: Move QEMU_INCLUDES before QEMU_CFLAGS

2011-08-10 Thread Jiri Denemark
This patch fixes build when any of the include paths from QEMU_CFLAGS contains a header file with similar name to a header file in qemu sources. I hit it with error.h included by qapi/qapi-types-core.h. GCC decided to use /usr/include/alsa/error.h instead of qemu's error.h. Signed-off-by: Jiri

Re: [Qemu-devel] [PATCH STABLE] build: Move QEMU_INCLUDES before QEMU_CFLAGS

2011-08-10 Thread Jiri Denemark
On Wed, Aug 10, 2011 at 16:04:15 +0300, Avi Kivity wrote: On 08/10/2011 01:04 PM, Jiri Denemark wrote: This patch fixes build when any of the include paths from QEMU_CFLAGS contains a header file with similar name to a header file in qemu sources. I hit it with error.h included by qapi/qapi

Re: [Qemu-devel] [QEMU PATCH 3/3] x86: pc: versioned CPU model names compatibility aliases

2012-07-26 Thread Jiri Denemark
On Wed, Jul 25, 2012 at 15:18:43 -0300, Eduardo Habkost wrote: This adds version number to CPU model names on the pc-version machine-types, so we can create new models with bug fixes while keeping compatibility when using older machine-types. When naming the existing models, I used the last

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

2012-03-26 Thread Jiri Denemark
On Sun, Mar 25, 2012 at 10:26:57 -0500, Anthony Liguori wrote: On 03/25/2012 10:16 AM, Avi Kivity wrote: On 03/25/2012 04:59 PM, Anthony Liguori wrote: So how about: 1) Load ['@SYSCONFDIR@/qemu/qemu.cfg', '@SYSCONFDIR@/qemu/target-@ARCH@.cfg', '@DATADIR@/system.cfg',

Re: [Qemu-devel] [libvirt] Qemu, libvirt, and CPU models

2012-03-08 Thread Jiri Denemark
On Wed, Mar 07, 2012 at 19:26:25 -0300, Eduardo Habkost wrote: Awesome. So, if Qemu and libvirt disagrees, libvirt will know that and add the necessary flags? That was my main worry. If disagreement between Qemu and libvirt is not a problem, it would make things much easier. ...but: Is

Re: [Qemu-devel] QEMU fstatfs(2) and libvirt SELinux policy

2012-03-09 Thread Jiri Denemark
Hi. On Fri, Mar 09, 2012 at 11:32:47 +, Stefan Hajnoczi wrote: ... static __inline__ int platform_test_xfs_fd(int fd) { struct statfs buf; if (fstatfs(fd, buf) 0) return 0; return (buf.f_type == 0x58465342); /* XFSB */ } In other words,

Re: [Qemu-devel] [PATCH qemu v3 0/6] -no-user-config option, move CPU models to /usr/share

2012-05-11 Thread Jiri Denemark
, having this in rc2 would be awesome. I already tested this patch set (at the time it was submitted) with my patches for libvirt which make use of it and it all worked very nicely and I was finally able to use all the new fancy CPUs :-) If it helps, you can count this as Tested-by: Jiri Denemark jdene

Re: [Qemu-devel] [PATCH 0/5] -no-user-config option, move CPU models to /usr/share

2012-04-19 Thread Jiri Denemark
On Wed, Apr 18, 2012 at 17:02:35 -0300, Eduardo Habkost wrote: This is the first try of the new -no-user-config option. Patches 1 to 3 just move some code around, patch 4 just adds the new option without adding any new config file. Patch 5 finally creates a /usr/share/qemu /cpus-x86_64.conf

Re: [Qemu-devel] [PATCH v2 06/24] qdev: fix -device foo,?

2012-04-27 Thread Jiri Denemark
On Wed, Apr 11, 2012 at 23:30:24 +0200, Paolo Bonzini wrote: Since most property types do not have a parse property now, this was broken. Fix it by looking at the setter instead. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- hw/qdev-monitor.c |4 ++-- 1 file changed, 2

Re: [Qemu-devel] libvirt-QEMU interfaces for CPU models

2013-03-01 Thread Jiri Denemark
On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote: Hi, After a long time trying to figure out the proper modelling inside QEMU, I believe the plans are now clearer in QEMU, so it's time to coordinate more closely with libvirt to try to make use of the new stuff. I tried to

Re: [Qemu-devel] libvirt-QEMU interfaces for CPU models

2013-03-01 Thread Jiri Denemark
On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote: = Querying host capabilities = Requirement: libvirt needs to know which feature can really be enabled, before it tries to start a VM, and before it tries to start a live-migration process. The set of available capabilities

Re: [Qemu-devel] libvirt-QEMU interfaces for CPU models

2013-03-01 Thread Jiri Denemark
On Fri, Mar 01, 2013 at 12:02:07 -0300, Eduardo Habkost wrote: On Fri, Mar 01, 2013 at 02:12:38PM +0100, Jiri Denemark wrote: Definitely, we plan to start using enforce flag as soon as we have better CPU probing interface with QEMU. Since libvirt does not currently consult CPU specs

Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event

2013-03-08 Thread Jiri Denemark
On Fri, Mar 08, 2013 at 09:50:55 +0100, Markus Armbruster wrote: Osier Yang jy...@redhat.com writes: I'm wondering if it could be long time to wait for the device_del completes (AFAIK from previous bugs, it can be, though it should be fine for most of the cases). If it's too long, it will

Re: [Qemu-devel] [PATCH V7 1/5] runstate: introduce prelaunch-migrate state

2013-03-11 Thread Jiri Denemark
On Thu, Mar 07, 2013 at 08:37:17 -0700, Eric Blake wrote: On 03/07/2013 01:23 AM, Jason Wang wrote: Sometimes, we need track the state when guest is just about to start after migration. There's not a accurate state available which do this accurately (consider qemu may started with -S in

Re: [Qemu-devel] [PATCH 0/2] target-i386: custom CPU model + script to dump existing CPU models

2015-06-08 Thread Jiri Denemark
On Mon, Jun 08, 2015 at 16:07:38 -0300, Eduardo Habkost wrote: ... libvirt can solve this problem partially by making sure every feature in a CPU model is explicitly configured, instead of (incorrectly) expecting that a named CPU model will never change in QEMU. But this doesn't solve the

Re: [Qemu-devel] [PATCH 0/2] target-i386: custom CPU model + script to dump existing CPU models

2015-06-24 Thread Jiri Denemark
On Tue, Jun 23, 2015 at 14:32:00 +0200, Andreas Färber wrote: Am 08.06.2015 um 22:18 schrieb Jiri Denemark: To help libvirt in the transition, a x86-cpu-model-dump script is provided, that will generate a config file that can be loaded using -readconfig, based on the -cpu and -machine

Re: [Qemu-devel] [PATCH 2/3] migration: create migration event

2015-05-29 Thread Jiri Denemark
On Wed, May 20, 2015 at 17:35:23 +0200, Juan Quintela wrote: We have one argument that tells us what event has happened. Signed-off-by: Juan Quintela quint...@redhat.com --- docs/qmp/qmp-events.txt | 16 migration/migration.c | 12 qapi/event.json |

Re: [Qemu-devel] [PATCH v4 0/3] Migration Events

2015-06-02 Thread Jiri Denemark
/libvir-list/2015-June/msg00064.html) and it all works very well. Thanks Juan, you can count this as Tested-by: Jiri Denemark jdene...@redhat.com Jirka

Re: [Qemu-devel] [PULL 24/28] migration: Make events a capability

2015-07-08 Thread Jiri Denemark
On Tue, Jul 07, 2015 at 15:09:05 +0200, Juan Quintela wrote: Make check fails with events. THis is due to the parser/lexer that it uses. Just in case that they are more broken parsers, just only send events when there are capabilities. Signed-off-by: Juan Quintela quint...@redhat.com

Re: [Qemu-devel] [PATCH v2 4/6] qmp: Add runnability information to query-cpu-definitions

2016-06-09 Thread Jiri Denemark
On Mon, Jun 06, 2016 at 17:05:41 -0300, Eduardo Habkost wrote: > Extend query-cpu-definitions schema to allow it to return two new > optional fields: "runnable" and "unavailable-features". > "runnable" will tell if the CPU model can be run in the current > host. "unavailable-features" will contain

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

2016-06-03 Thread Jiri Denemark
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 applies > > them to it while doing parsing. > > > >

Re: [Qemu-devel] [libvirt] inconsistent handling of "qemu64" CPU model

2016-05-26 Thread Jiri Denemark
On Wed, May 25, 2016 at 23:13:24 -0600, Chris Friesen wrote: > Hi, > > If I don't specify a virtual CPU model, it appears to give me a "qemu64" CPU, > and /proc/cpuinfo in the guest instance looks something like this: > > processor 0 > vendor_id GenuineIntel > cpu family 6 > model 6 > model

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

2016-06-22 Thread Jiri Denemark
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

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

2016-06-22 Thread Jiri Denemark
On Wed, Jun 22, 2016 at 08:51:40 +0200, David Hildenbrand wrote: > > 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: > > > I still don't think we want to set in stone that "the result the > > > guest sees

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

2016-06-22 Thread Jiri Denemark
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 s390x. > > What we could do to avoid one

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

2016-06-22 Thread Jiri Denemark
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 > > > _with_ this additional query. Meaning the involved overhead

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

2016-06-21 Thread Jiri Denemark
On Mon, Jun 20, 2016 at 17:09:18 -0300, Eduardo Habkost wrote: > > Ping? No other feedback on this? The interface is fine from my point of view and I even have a working libvirt code that consumes this. Jirka

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

2016-06-21 Thread Jiri Denemark
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 > > that we also want to have features exposed via the CPU

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

2016-06-21 Thread Jiri Denemark
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 wrote: > > > > This is our second attempt to implement CPU

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

2016-05-12 Thread Jiri Denemark
On Wed, May 11, 2016 at 16:35:50 -0300, Eduardo Habkost wrote: > # @CpuDefinitionInfo: > # > # Virtual CPU definition. > # > # @name: the name of the CPU definition > # @runnable: #optional. whether the CPU model us usable with the s/ us / is / > #current machine and accelerator.

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

2016-05-10 Thread Jiri Denemark
l contain a list of 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.i

Re: [Qemu-devel] [PATCH 8/9] target-i386: Use "-" instead of "_" on all feature names

2016-05-10 Thread Jiri Denemark
On Tue, May 10, 2016 at 17:19:51 +0200, Igor Mammedov wrote: > On Fri, 6 May 2016 15:11:31 -0300 > Eduardo Habkost wrote: > > > This makes the feature name tables in feature_word_info all match > > the actual QOM property names we use. > > > > This will make the

Re: [Qemu-devel] [PATCH v4 05/11] target-i386: Remove underscores from property names

2016-09-30 Thread Jiri Denemark
On Thu, Sep 29, 2016 at 18:14:53 -0300, Eduardo Habkost wrote: > Instead of translating the feature name entries when adding > property names, store the actual property names in the feature > name array. > > Signed-off-by: Eduardo Habkost > --- > Changes series v3 -> v4: > *

Re: [Qemu-devel] [PATCH v4 01/11] tests: Add test case for x86 feature parsing compatibility

2016-09-30 Thread Jiri Denemark
On Fri, Sep 30, 2016 at 09:55:33 +0200, Paolo Bonzini wrote: > > > On 29/09/2016 23:14, Eduardo Habkost wrote: > > + * "-foo" overrides "+foo" > > + * "[+-]foo" overrides "foo=..." > > Is this something that people are actually using? Can we detect it and > deprecate it in 2.8, and

Re: [Qemu-devel] QMP stubs: how to return "not implemented" errors?

2016-10-03 Thread Jiri Denemark
On Mon, Oct 03, 2016 at 16:04:42 -0300, Eduardo Habkost wrote: > Hi, > > When adding new QMP commands that are implemented by > arch-specific code, we have been adding stubs that report > QERR_UNSUPPORTED (see stubs/arch-query-cpu-model-expansion.c for > an example). > > But we are using

Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

2016-11-11 Thread Jiri Denemark
On Tue, Nov 08, 2016 at 08:29:41 +0100, Markus Armbruster wrote: > Eduardo Habkost writes: > > libvirt wants to know if the QEMU binary supports a given -cpu > > option (normally CPU features that can be enabled/disabled using > > "+foo"/"-foo"). > > The obvious way to check

Re: [Qemu-devel] [libvirt] [PATCH v1] qemu: command: rework cpu feature argument support

2016-11-16 Thread Jiri Denemark
On Tue, Nov 15, 2016 at 11:44:00 -0200, Eduardo Habkost wrote: > CCing qemu-devel. > > CCing Markus, in case he has any insights about the interface > introspection. > > On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote: > > On Mon, Nov 14, 2016 at 18:02:2

Re: [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base" CPU model

2016-12-16 Thread Jiri Denemark
On Mon, Dec 05, 2016 at 21:57:45 -0200, Eduardo Habkost wrote: > On Mon, Dec 05, 2016 at 07:18:47PM +0100, David Hildenbrand wrote: > > Am 02.12.2016 um 22:18 schrieb Eduardo Habkost: > > > The query-cpu-model-expand QMP command needs at least one static > > > model, to allow the "static"

Re: [Qemu-devel] [PATCH for-2.9 v2 0/2] i386: Don't override -cpu options on -cpu host/max

2017-03-28 Thread Jiri Denemark
pu_expand_features(). What makes this bug worse now is that > libvirt 3.0.0 and newer now use "feat=on|off" instead of > +feat/-feat when it detects a QEMU version that supports it (see > libvirt commit d47db7b16dd5422c7e487c8c8ee5b181a2f9cd66). > > This series fixes the bug. Thanks. Tested-by: Jiri Denemark <jdene...@redhat.com> Jirka

Re: [Qemu-devel] host doesn't support requested feature: CPUID.01H:EDX.ds [bit 21] Does this warn affect virtual machine performance or use?

2017-09-15 Thread Jiri Denemark
On Thu, Sep 14, 2017 at 20:48:49 +0800, Paul Schlacter wrote: > this is my stackoverflow question: > https://stackoverflow.com/questions/46219552/host-doesnt-support-requested-feature-cpuid-01hedx-ds-bit-21-does-this-warn > > > I found a lot of warning from the VM qemu log, Does this warn affect

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

2017-10-20 Thread Jiri Denemark
On Fri, Oct 20, 2017 at 13:09:26 +0200, Marc Hartmayer wrote: > we recently encountered the problem that the 'host-model' [1] has to be > related to the machine type of a domain. We have following problem: > >Let's assume we've a z13 system with a QEMU 2.9 and we define a >domain using

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

2017-10-20 Thread Jiri Denemark
On Fri, Oct 20, 2017 at 13:37:42 +0200, David Hildenbrand wrote: > On 20.10.2017 13:09, Marc Hartmayer wrote: > > we recently encountered the problem that the 'host-model' [1] has to be > > related to the machine type of a domain. We have following problem: > > > >Let's assume we've a z13

Re: [Qemu-devel] [PATCH v3 0/7] migration: pause-before-switchover

2017-10-19 Thread Jiri Denemark
The libvirt changes which will make use of this new migration capability can be found in migration-pause branch of my gitlab repository: git fetch https://gitlab.com/jirkade/libvirt.git migration-pause It's not properly split into patches, it has no commit message etc., but the functionality

Re: [Qemu-devel] [PATCH v3 4/7] migration: migrate-continue

2017-10-19 Thread Jiri Denemark
On Wed, Oct 18, 2017 at 18:40:10 +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" > > A new qmp command allows the caller to continue from a given > paused state. > > Signed-off-by: Dr. David Alan Gilbert ... > diff --git

Re: [Qemu-devel] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines

2017-10-27 Thread Jiri Denemark
On Thu, Oct 26, 2017 at 10:09:46 +0200, David Hildenbrand wrote: > On 25.10.2017 18:45, Marc Hartmayer wrote: > > On Wed, Oct 25, 2017 at 05:50 PM +0200, David Hildenbrand > > wrote: > >> On 25.10.2017 17:09, Boris Fiuczynski wrote: > >>> David, I disagree if your proposal is

Re: [Qemu-devel] [libvirt] Question about the host-model CPU mode

2017-10-23 Thread Jiri Denemark
On Fri, Oct 20, 2017 at 15:04:57 +0200, David Hildenbrand wrote: > On 20.10.2017 14:50, Jiri Denemark wrote: > > The thing is libvirt calls query-cpu-model-expansion to check what the > > host CPU is. This 'host-model' CPU is replaced with the probed CPU model > > when a domai

Re: [Qemu-devel] [libvirt] [PATCH/QEMU] s390x/kvm: use cpu_model_available for guarded storage on compat machines

2017-10-27 Thread Jiri Denemark
On Fri, Oct 27, 2017 at 17:18:44 +0200, Halil Pasic wrote: > On 10/27/2017 04:06 PM, Christian Borntraeger wrote: ... > > I talked to several people and it seems that on x86 the host model will > > also enable new features > > that are not known by older QEMUs and its considered works as

Re: [Qemu-devel] [PATCH RESEND v1 1/2] i386: Add Intel Processor Trace feature support

2018-01-15 Thread Jiri Denemark
On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote: > CCing libvirt developers. ... > This case is slightly more problematic, however: the new feature > is actually migratable (under very controlled circumstances) > because of patch 2/2, but it is not migration-safe[1]. This > means

Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S

2018-04-09 Thread Jiri Denemark
On Wed, Apr 04, 2018 at 12:03:03 +0200, Kevin Wolf wrote: > Am 03.04.2018 um 22:52 hat Dr. David Alan Gilbert geschrieben: > > * Kevin Wolf (kw...@redhat.com) wrote: > > > Consider a case where the management tool keeps a mirror job with > > > sync=none running to expose all I/O requests to some

Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S

2018-04-11 Thread Jiri Denemark
On Tue, Apr 10, 2018 at 16:47:56 +0200, Kevin Wolf wrote: > Am 10.04.2018 um 16:22 hat Dr. David Alan Gilbert geschrieben: > > * Kevin Wolf (kw...@redhat.com) wrote: > > > Am 10.04.2018 um 12:40 hat Dr. David Alan Gilbert geschrieben: > > > > Hmm; having chatted to Jiri I'm OK with reverting it,

Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S

2018-04-10 Thread Jiri Denemark
On Mon, Apr 09, 2018 at 15:40:03 +0200, Kevin Wolf wrote: > Am 09.04.2018 um 12:27 hat Dr. David Alan Gilbert geschrieben: > > It's a fairly hairy failure case they had; if I remember correctly it's: > > a) Start migration > > b) Migration gets to completion point > > c) Destination is still

Re: [Qemu-devel] [libvirt] CPU model versioning separate from machine type versioning ?

2018-06-29 Thread Jiri Denemark
On Thu, Jun 28, 2018 at 16:23:53 -0300, Eduardo Habkost wrote: > On Thu, Jun 28, 2018 at 07:59:38PM +0100, Dr. David Alan Gilbert wrote: > [...] > > > An application like virt-manager which wants a simple UI can forever be > > > happy simply giving users a list of bare CPU model names, and

Re: [Qemu-devel] CPU model versioning separate from machine type versioning ?

2018-06-29 Thread Jiri Denemark
On Fri, Jun 29, 2018 at 11:14:17 +0100, Daniel P. Berrangé wrote: > On Thu, Jun 28, 2018 at 04:52:27PM -0300, Eduardo Habkost wrote: > > On Thu, Jun 28, 2018 at 04:45:02PM +0100, Daniel P. Berrangé wrote: > > [...] > > > What if we can borrow the concept of versioning from machine types and > > >

[Qemu-devel] Dropped CPU feature names and backward compatibility

2018-09-18 Thread Jiri Denemark
Hi, I noticed two x86_64 CPU features were removed from QEMU in 3.0.0: - ospke removed by 9ccb9784b57 - osxsave removed by f1a23522b03 More precisely, the CPUID bits are still there (and for example Icelake CPU model has the ospke bit set), but the string representations were removed.

Re: [Qemu-devel] Dropped CPU feature names and backward compatibility

2018-09-18 Thread Jiri Denemark
On Tue, Sep 18, 2018 at 10:14:45 -0300, Eduardo Habkost wrote: > On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote: > > Sure, libvirt could just avoid passing feature=off for any feature which > > is not supported by the QEMU binary it is about to start since such >

Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property

2019-05-09 Thread Jiri Denemark
On Mon, Apr 22, 2019 at 20:47:40 -0300, Eduardo Habkost wrote: > Currently, libvirt uses the "filtered-features" QOM property at > runtime to ensure no feature was accidentally disabled on VCPUs > because it's not available on the host. > > However, the code for "feature-words" assumes that all

Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property

2019-05-09 Thread Jiri Denemark
On Thu, May 09, 2019 at 10:56:17 -0300, Eduardo Habkost wrote: > On Thu, May 09, 2019 at 03:35:37PM +0200, Jiri Denemark wrote: > > Would this unavailable-features property contain only canonical names of > > the features or all possible aliases of all features? For example, >

Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property

2019-05-09 Thread Jiri Denemark
On Thu, May 09, 2019 at 18:06:03 +0200, Igor Mammedov wrote: > On Thu, 9 May 2019 10:56:17 -0300 > Eduardo Habkost wrote: > > > On Thu, May 09, 2019 at 03:35:37PM +0200, Jiri Denemark wrote: > > > Would this unavailable-features property contain only canonical names of &

Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property

2019-05-22 Thread Jiri Denemark
On Fri, May 10, 2019 at 17:32:03 -0300, Eduardo Habkost wrote: > On Thu, May 09, 2019 at 06:36:18PM +0200, Jiri Denemark wrote: > > On Thu, May 09, 2019 at 18:06:03 +0200, Igor Mammedov wrote: > > > On Thu, 9 May 2019 10:56:17 -0300 > > > Eduardo Habkost wrote: > >

Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property

2019-05-22 Thread Jiri Denemark
On Fri, May 10, 2019 at 17:23:13 -0300, Eduardo Habkost wrote: > On Fri, May 10, 2019 at 01:33:03PM +0200, Jiri Denemark wrote: > > On Thu, May 09, 2019 at 13:08:25 -0300, Eduardo Habkost wrote: > > > On Thu, May 09, 2019 at 05:26:16PM +0200, Jiri Denemark wrote: > > > &

Re: [Qemu-devel] [PATCH 0/2] i386: "unavailable-features" QOM property

2019-05-10 Thread Jiri Denemark
On Thu, May 09, 2019 at 13:08:25 -0300, Eduardo Habkost wrote: > On Thu, May 09, 2019 at 05:26:16PM +0200, Jiri Denemark wrote: > > On Thu, May 09, 2019 at 10:56:17 -0300, Eduardo Habkost wrote: > > > On Thu, May 09, 2019 at 03:35:37PM +0200, Jiri Denemark wrote: > > &g

Re: [Qemu-devel] [PATCH 1/1] x86: add CPU flags supported inside libvirt

2019-08-14 Thread Jiri Denemark
On Thu, Jul 18, 2019 at 16:45:37 +0300, Denis V. Lunev wrote: > There are the following flags available in libvirt inside cpu_map.xm > > > > > > > We have faced the problem that QEMU does not start once these flags are > present in the domain.xml. Libvirt should

Re: [RFC] cpu_map: Remove pconfig from Icelake-Server CPU model

2019-09-30 Thread Jiri Denemark
On Mon, Sep 30, 2019 at 17:16:27 +0200, Paolo Bonzini wrote: > On 30/09/19 16:31, Hu, Robert wrote: > >> This might be a problem if there are plans to eventually make KVM support > >> pconfig, though. Paolo, Robert, are there plans to support pconfig in KVM > >> in the > >> future? > > [Robert

Re: [PATCH] spapr/kvm: Set default cpu model for all machine classes

2019-11-01 Thread Jiri Denemark
-mem-supported": true, > "default-cpu-type": "host-powerpc64-cpu", > "cpu-max": 1024, > "deprecated": false > }, > ... > > Libvirt probes all machines via "-machine none,accel=kvm:tcg" and will > currently see the wrong CPU model under KVM. > > Reported-by: Jiři Denemark > Cc: David Hildenbrand > Cc: Igor Mammedov Works as expected now, thanks. Tested-by: Jiri Denemark

Re: [PATCH] spapr/kvm: Set default cpu model for all machine classes

2019-11-13 Thread Jiri Denemark
Hi David. On Wed, Oct 30, 2019 at 17:32:43 +0100, David Gibson wrote: > We have to set the default model of all machine classes, not just for the > active one. Otherwise, "query-machines" will indicate the wrong CPU model > ("qemu-s390x-cpu" instead of "host-s390x-cpu") as "default-cpu-type". >

Re: Default CPU models on s390x and ppc64

2019-10-18 Thread Jiri Denemark
On Thu, Oct 17, 2019 at 17:13:10 +0100, Peter Maydell wrote: > On Thu, 17 Oct 2019 at 17:09, David Hildenbrand wrote: > > The default model under KVM is "host", under TCG it's "qemu". We should > > not use "qemu" under KVM, although it might work on some setups ... > > Possibly a tangent, but on

Re: Default CPU models on s390x and ppc64

2019-10-18 Thread Jiri Denemark
On Thu, Oct 17, 2019 at 17:35:30 +0200, David Hildenbrand wrote: > On 17.10.19 17:31, David Hildenbrand wrote: > > On 17.10.19 17:18, David Hildenbrand wrote: > >> On 17.10.19 17:16, Jiri Denemark wrote: > >>> Hi David and David, > >>> > >>> I

Default CPU models on s390x and ppc64

2019-10-17 Thread Jiri Denemark
Hi David and David, I'm working on libvirt's support [1] for query-machines' default-cpu-type, which is supposed to return the type of the default CPU model that QEMU uses for each machine type. Rather than hard coding the default in libvirt (which we currently do on x86), we ask QEMU for the

Re: [libvirt] [RFC] cpu_map: Remove pconfig from Icelake-Server CPU model

2019-10-03 Thread Jiri Denemark
On Tue, Oct 01, 2019 at 11:20:42 +0200, Paolo Bonzini wrote: > On 30/09/19 18:16, Jiri Denemark wrote: > > On Mon, Sep 30, 2019 at 17:16:27 +0200, Paolo Bonzini wrote: > >> On 30/09/19 16:31, Hu, Robert wrote: > >>>> This might be a problem if there are pla