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
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
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
On Fri, Mar 08, 2013 at 09:50:55 +0100, Markus Armbruster wrote:
> Osier Yang 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 be a pro
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
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', '@DATA
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 somewher
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-objec
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
> +-
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:
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 wit
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.c
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:
>
>
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 oth
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
> ---
> docs/qmp/qmp-events.txt | 16
> migration/migration.c | 12
> qapi/event.json | 14 +
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,
> &
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 di
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
> ---
> hw/qdev-monitor.c |4 ++--
> 1 file changed, 2 insertions(+), 2 del
and am testing it right now for -rc2.
Oh, 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 co
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, Copyr
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
-nodefc
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 i
^ and tested it with
libvirt patches I just sent to the list
(https://www.redhat.com/archives/libvir-list/2015-June/msg00064.html)
and it all works very well.
Thanks Juan, you can count this as
Tested-by: Jiri Denemark
Jirka
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
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
> Reviewed-by: Dr. D
On Wed, Jul 25, 2012 at 15:18:43 -0300, Eduardo Habkost wrote:
> This adds version number to CPU model names on the "pc-"
> 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 Q
;> > 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
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 name
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.
> >
> > That
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
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
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 mo
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 models
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 thin
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 when
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 compare
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 would
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 command-line interface more cons
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. Omit
From: Jiri Denemark
Non-existent $pkgconfig instead of $pkg_config was used when configure
probes for spice availability.
Signed-off-by: Jiri Denemark
---
configure |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index 210670c..dc469b2
On Mon, Jan 24, 2011 at 15:01:27 +0100, Gerd Hoffmann wrote:
> On 01/24/11 13:20, Jiri Denemark wrote:
> > From: Jiri Denemark
> >
> > Non-existent $pkgconfig instead of $pkg_config was used when configure
> > probes for spice availability.
>
> What tree you are l
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 Denemark
> > >
> > > Non-existent $pkgconfig instead of $pkg_config was
Late initialization of CPU topology in CPUState prevents KVM guests to
actually see the topology.
Signed-off-by: Jiri Denemark
---
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/vl.c
@@ -3484,10
On Wed, Feb 07, 2024 at 12:37:15 +0800, Peter Xu wrote:
> On Wed, Feb 07, 2024 at 12:13:10PM +0800, Peter Xu wrote:
> > On Tue, Feb 06, 2024 at 11:19:04PM +, Hao Xiang wrote:
> > > This change extends the MigrationStatus interface to track zero pages
> > > and zero bytes counter.
> > >
> > > S
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 mi
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,
>
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
&
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
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 defa
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
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
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
On Thu, May 11, 2023 at 13:43:47 +0200, Juan Quintela wrote:
> "Michael S. Tsirkin" wrote:
>
> [Added libvirt people to the party, see the end of the message ]
Sorry, I'm not that much into parties :-)
> That would fix the:
>
> qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
>
> It is worth it? D
On Mon, Jun 12, 2023 at 21:33:38 +0200, Juan Quintela wrote:
> Hi this series describe the migration parts that have to be deprecated.
>
> - It is an rfc because I doubt that I did the deprecation process right.
> Hello Markus O:-)
>
> - skipped field: It is older than me, I have never know what
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 whether a specific CP
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
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 GenericE
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 lib
x86_cpu_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
Jirka
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. Thu
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
> &
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 allowing
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
> > >
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
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" expansion
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 a/qapi/migration.json b/qapi/migration.json
>
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
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 the
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 syst
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
> > wh
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 to generally tolerat
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 designed.
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:
> * New patch added to se
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 drop
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 ex
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
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, on
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 Ho
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
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".
>
>
-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
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:
> >
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:
> > > &
83 matches
Mail list logo
