qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <dahi@linux.vnet.ibm.com>
To: Jiri Denemark <jdenemar@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
	peter.maydell@linaro.org, ehabkost@redhat.com,
	mark.cave-ayland@ilande.co.uk, qemu-devel@nongnu.org,
	blauwirbel@gmail.com, qemu-arm@nongnu.org, pbonzini@redhat.com,
	rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties
Date: Fri, 3 Jun 2016 14:14:26 +0200	[thread overview]
Message-ID: <20160603141426.6d6ad708@thinkpad-w530> (raw)
In-Reply-To: <20160603120658.GF40539@orkuz.home>

> 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 doesn't work well with -device/device_add infrastructure
> > > as it has no idea about cpu specific hooks that's used for
> > > parsing "features".
> > > In order to make -device/device_add utilize "-cpu features"
> > > template convert it into a set of global properties, so that
> > > every new CPU created will have them applied automatically.
> > > 
> > > That also allows to parse features only once, instread of
> > > doing it for every CPU instance created.  
> > 
> > While I think this makes sense for most cases, we (s390x) are
> > currently working on a mechanism to compare and baseline cpu models via
> > a qmp interface, to not have to replicate CPU models in libvirt
> > every time we do some changes.  
> 
> BTW, we don't replicate any change to QEMU CPU models in libvirt. We
> merely add new CPU models that match the current QEMU definition.
> Existing CPU models are never changed. And while the CPU models are
> currently used to check compatibility with host CPU, we will stop doing
> that in the near future and our CPU models will mostly be used for
> detecting what the host CPU is.
> 
> Jirka
> 


Hi Jirka,

thanks for that info!

unfortunately we will have to perform changes to the cpu models.
On z we have various cpu features that are confidential and only
added over time, although they are around for quite some time.
And we have features that are not implemented yet by KVM and will not
be implemented in the near future.
Therefore we will be adding features to our "flexible models"
while keeping migration safe variants with base features stable.

Some day in the future, we will also have all features around :)

Another problematic thing for us is, that we really have to rely
on a host cpu model detection using KVM. The features that
are visible in user space (similar to cpuid()) don't give any
guarantees to what we are able to virtualize.

David

  reply	other threads:[~2016-06-03 12:14 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01 16:37 [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties Igor Mammedov
2016-06-01 16:37 ` [Qemu-devel] [PATCH RFC 1/8] target-i386: cpu: move features logic that requires CPUState to realize time Igor Mammedov
2016-06-01 17:43   ` Eduardo Habkost
2016-06-02  9:59     ` Igor Mammedov
2016-06-02 14:38       ` Eduardo Habkost
2016-06-02 16:56         ` Igor Mammedov
2016-06-02 17:34           ` Eduardo Habkost
2016-06-02 18:23             ` Igor Mammedov
2016-06-02 18:43               ` Eduardo Habkost
2016-06-03 10:13             ` Igor Mammedov
2016-06-03 19:26               ` Eduardo Habkost
2016-06-04 16:44                 ` Igor Mammedov
2016-06-01 16:37 ` [Qemu-devel] [PATCH RFC 2/8] target-i386: cpu: move xcc->kvm_required check to reaize time Igor Mammedov
2016-06-01 17:46   ` Eduardo Habkost
2016-06-02 10:02     ` Igor Mammedov
2016-06-01 16:37 ` [Qemu-devel] [PATCH RFC 3/8] target-i386: cpu: use cpu_generic_init() in cpu_x86_init() Igor Mammedov
2016-06-01 18:08   ` Eduardo Habkost
2016-06-01 16:37 ` [Qemu-devel] [PATCH RFC 4/8] target-i386: cpu: consolidate calls of object_property_parse() in x86_cpu_parse_featurestr Igor Mammedov
2016-06-01 18:46   ` Eduardo Habkost
2016-06-02 12:22     ` Igor Mammedov
2016-06-02 14:42       ` Eduardo Habkost
2016-06-02 14:53       ` Eduardo Habkost
2016-06-02 15:05         ` Peter Krempa
2016-06-02 16:31           ` Igor Mammedov
2016-06-03  7:30             ` Peter Krempa
2016-06-03  9:37               ` Igor Mammedov
2016-06-03 19:36                 ` Eduardo Habkost
2016-06-02 16:32         ` Igor Mammedov
2016-06-02 16:55           ` [Qemu-devel] [PATCH] target-i386: Remove xlevel & hv-spinlocks option fixups Eduardo Habkost
2016-06-02 21:07             ` [Qemu-devel] [libvirt] " Eric Blake
2016-06-01 16:37 ` [Qemu-devel] [PATCH RFC 5/8] target-sparc: cpu: use sparc_cpu_parse_features() directly Igor Mammedov
2016-06-01 16:37 ` [Qemu-devel] [PATCH RFC 6/8] cpu: use CPUClass->parse_features() as convertor to global properties Igor Mammedov
2016-06-01 18:54   ` Eduardo Habkost
2016-06-02 10:06     ` Igor Mammedov
2016-06-02 14:41       ` Eduardo Habkost
2016-06-01 16:37 ` [Qemu-devel] [PATCH RFC 7/8] arm: virt: parse cpu_model only once Igor Mammedov
2016-06-01 16:37 ` [Qemu-devel] [PATCH RFC 8/8] pc: parse cpu features " Igor Mammedov
2016-06-01 18:21 ` [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties Peter Maydell
2016-06-01 18:51   ` Eduardo Habkost
2016-06-02 20:44 ` David Hildenbrand
2016-06-03 12:06   ` Jiri Denemark
2016-06-03 12:14     ` David Hildenbrand [this message]
     [not found] ` <201606022044.u52KaIkv017063@mx0a-001b2d01.pphosted.com>
2016-06-03  0:02   ` Eduardo Habkost
2016-06-03  6:36     ` David Hildenbrand
     [not found]     ` <20160603083621.6547bde4@thinkpad-w530>
2016-06-03  9:20       ` Igor Mammedov
2016-06-03 10:18         ` David Hildenbrand
2016-06-03 19:54       ` Eduardo Habkost
2016-06-06  9:59         ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160603141426.6d6ad708@thinkpad-w530 \
    --to=dahi@linux.vnet.ibm.com \
    --cc=blauwirbel@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).