[libvirt] [PATCH] Fix qemudDomainShutdown() memory leak

[Eduardo Habkost]

qemudDomainShutdown() currently doesn't free the returned reply from
qemudMonitorCommand().

Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
 src/qemu_driver.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 806608d..a88cb75 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2176,6 +2176,7 @@ static int qemudDomainShutdown(virDomainPtr dom) {
  %s, _(shutdown operation failed));
 return -1;
 }
+VIR_FREE(info);
 return 0;
 
 }
-- 
1.5.5.GIT

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Reboot support for QEMU/KVM

[Eduardo Habkost]

This patch implements reboot support on qemu_driver.

It is so simple that I am wondering if there is some problem I am missing,
that would be the reason it wasn't implemented yet. I hope not.  :)

Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
---
 src/qemu_driver.c |   23 ++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index a88cb75..9ce53ad 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2182,6 +2182,27 @@ static int qemudDomainShutdown(virDomainPtr dom) {
 }
 
 
+static int qemudDomainReboot(virDomainPtr dom) {
+struct qemud_driver *driver = (struct qemud_driver 
*)dom-conn-privateData;
+virDomainObjPtr vm = virDomainFindByID(driver-domains, dom-id);
+char* info;
+
+if (!vm) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_INVALID_DOMAIN,
+ _(no domain with matching id %d), dom-id);
+return -1;
+}
+
+if (qemudMonitorCommand(driver, vm, system_reset, info)  0) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ %s, _(reboot operation failed));
+return -1;
+}
+VIR_FREE(info);
+return 0;
+}
+
+
 static int qemudDomainDestroy(virDomainPtr dom) {
 struct qemud_driver *driver = (struct qemud_driver 
*)dom-conn-privateData;
 virDomainObjPtr vm = virDomainFindByID(driver-domains, dom-id);
@@ -4032,7 +4053,7 @@ static virDriver qemuDriver = {
 qemudDomainSuspend, /* domainSuspend */
 qemudDomainResume, /* domainResume */
 qemudDomainShutdown, /* domainShutdown */
-NULL, /* domainReboot */
+qemudDomainReboot, /* domainReboot */
 qemudDomainDestroy, /* domainDestroy */
 qemudDomainGetOSType, /* domainGetOSType */
 qemudDomainGetMaxMemory, /* domainGetMaxMemory */
-- 
1.5.5.GIT

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Reboot support for QEMU/KVM

[Eduardo Habkost]

On Tue, Oct 07, 2008 at 09:58:47PM +0100, Daniel P. Berrange wrote:
 On Tue, Oct 07, 2008 at 05:55:37PM -0300, Eduardo Habkost wrote:
  This patch implements reboot support on qemu_driver.
  
  It is so simple that I am wondering if there is some problem I am missing,
  that would be the reason it wasn't implemented yet. I hope not.  :)
 
 The reboot command is intended todo a controlled shutdown, followed by
 warm restart. Doesn't the system_reset command do an immediate warm 
 reboot ?

Yes, it does. Sorry, I should have read the virDomainReboot() description
on the API documentation first.

 
 I think we needs to happen is that we invoke the 'system_shutdown'
 command, and when we detect the VM has quit, then manually start
 it again. This is technically a cold reboot, but its close enough

It would be better than not supporting reboot at all.

Maybe libvirt itself could fallback to this if reboot is not implemented?
If not, maybe the UIs using libvirt could do that?

-- 
Eduardo

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [Libvir] libvirt statistics

[Eduardo Habkost]

Hi,

On Thu, Sep 06, 2007 at 02:10:39PM +0100, Richard W.M. Jones wrote:
 [Using `pahole' and friends - see 
 http://git.kernel.org/?p=linux/kernel/git/acme/pahole.git;a=summary and 
 https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf ]
 
 These are all on x86-64.  You'll get slightly different results on a 32 
 bit arch.
 
 Largest structures, by size:
 
 qemud_vm_def: 16608 4
 qemud_vm_os_def: 16436 1
 _testConn: 14504 2
snip

What is the second field here?


 
 Structures with holes which could be made smaller by packaging (third 
 number is how many bytes you'd save per allocation):
 
snip
 _xmlValidCtxt  112   104 8
 _xmlEntity 136   128 8
 _xmlParserCtxt 696   67224
 _testConn14504 14496 8
 _xmlURI 8072 8
 _xmlXPathObject 725616
 _xmlXPathParserContext  8072 8
 _xmlXPathContext   352   33616
 _xmlError   8880 8
 _xmlAttr9688 8
 _xmlDoc168   160 8
 _xmlNode   120   112 8

Are those defined by libxml, or are they from the libvirt code?

 
 Functions with the most parameters (in C these are dangerous because of 
 C's lousy typechecking):
 
 __virRaiseError: 12

12 parameters, wow!

 
 All global variables (nothing wrong with global variables, I say):
 
 extern unsigned int   __invalid_size_argument_for_IOC; /* 0 */

Doesn't seem to be from libvirt code.

 struct qemu_feature_flags  arch_info_i686_flags[4]; /* 0 */
 struct qemu_feature_flags  arch_info_x86_64_flags[3]; /* 0 */
 struct qemud_driver *  qemu_driver; /* 0 */
 struct qemu_arch_info  qemudArchs[7]; /* 1 */

Not many. The arrays smell like constant data, that wouldn't be
a Bad Thing being global. Some may be made static, however.


 extern struct _IO_FILE *  stderr; /* 9 */
 extern struct _IO_FILE *  stdin; /* 23 */
 extern struct _IO_FILE *  stdout; /* 23 */

System variables.


 enum /**/ virDrvOpenRemoteFlags; /* 0 */

I think this was supposed to be a type definition. The variable is
never used.

 struct xenUnifiedDriverxenDaemonDriver; /* 1 */
 struct xenUnifiedDriverxenHypervisorDriver; /* 1 */
 struct xenUnifiedDriverxenProxyDriver; /* 1 */
 struct xenUnifiedDriverxenStoreDriver; /* 1 */
 struct xenUnifiedDriverxenXMDriver; /* 1 */

Those seem to work like class definitions, so they are not a Bad
Thing, too.

 extern xmlFreeFuncxmlFree; /* 3 */
 extern xmlMallocFunc  xmlMalloc; /* 0 */

Not from libvirt code.

-- 
Eduardo


pgpZaw5ww4LAw.pgp
Description: PGP signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Qemu, libvirt, and CPU models

[Eduardo Habkost]

Hi,

Sorry for the long message, but I didn't find a way to summarize the
questions and issues and make it shorter.

For people who don't know me: I have started to work recently on the
Qemu CPU model code. I have been looking at how things work on
libvirt+Qemu today w.r.t. CPU models, and I have some points I would
like to understand better and see if they can be improved.

I have two main points I would like to understand/discuss:

1) The relationship between libvirt's cpu_map.xml and the Qemu CPU model
   definitions.

2) How we could properly allow CPU models to be changed without breaking
   existing virtual machines?

Note that for all the questions below, I don't expect that we design the
whole solution and discuss every single detail in this thread. I just
want to collectn suggestions, information about libvirt requirements and
assumptions, and warnings about expected pitfalls before I start working
on a solution on Qemu.


1) Qemu and cpu_map.xml

I would like to understand how cpu_map.xml is supposed to be used, and
how it is supposed to interact with the CPU model definitions provided
by Qemu. More precisely:

1.1) Do we want to eliminate the duplication between the Qemu CPU
  definitions and cpu_map.xml?

1.1.1) If we want to eliminate the duplication, how can we accomplish
  that? What interfaces you miss, that Qemu could provide?

1.1.2) If the duplication has a purpose and you want to keep
  cpu_map.xml, then:
  - First, I would like to understand why libvirt needs cpu_map.xml? Is
it part of the public interface of libvirt, or is it just an
internal file where libvirt stores non-user-visible data?
  - How can we make sure there is no confusion between libvirt and Qemu
about the CPU models? For example, what if cpu_map.xml says model
'Moo' has the flag 'foo' enabled, but Qemu disagrees? How do we
guarantee that libvirt gets exactly what it expects from Qemu when
it asks for a CPU model? We have -cpu ?dump today, but it's not
the better interface we could have. Do you miss something in special
in the Qemu-libvirt interface, to help on that?

1.2) About the probing of available features on the host system: Qemu
  has code specialized to query KVM about the available features, and to
  check what can be enabled and what can't be enabled in a VM. On many
  cases, the available features match exactly what is returned by the
  CPUID instruction on the host system, but there are some
  exceptions:
  - Some features can be enabled even when the host CPU doesn't support
it (because they are completely emulated by KVM, e.g. x2apic).
  - On many other cases, the feature may be available but we have to
check if Qemu+KVM are really able to expose it to the guest (many
features work this way, as many depend on specific support by the
KVM kernel module and/or Qemu).
  
  I suppose libvirt does want to check which flags can be enabled in a
  VM, as it already have checks for host CPU features (e.g.
  src/cpu/cpu_x86.c:x86Compute()). But I also suppose that libvirt
  doesn't want to duplicate the KVM feature probing code present on
  Qemu, and in this case we could have an interface where libvirt could
  query for the actually-available CPU features. Would it be useful for
  libvirt? What's the best way to expose this interface?

1.3) Some features are not plain CPU feature bits: e.g. level=X can be
  set in -cpu argument, and other features are enabled/disabled by
  exposing specific CPUID leafs and not just a feature bit (e.g. PMU
  CPUID leaf support). I suppose libvirt wants to be able to probe for
  those features too, and be able to enable/disable them, right?



2) How to change an existing model and keep existing VMs working?

Sometimes we have to update a CPU model definition because of some bug.
Eamples:

- The CPU models Conroe, Penrym and Nehalem, have level=2 set. This
  works most times, but it breaks CPU core/thread topology enumeration.
  We have to change those CPU models to use level=4 to fix the bug.

- This can happen with plain CPU feature bits, too, not just level:
  sometimes real-world CPU models have a feature that is not supported
  by Qemu+KVM yet, but when the kernel and Qemu finally starts to
  support it, we may want to enable it on existing CPU models. Sometimes
  a model simply has the wrong set of feature bits, and we have to fix
  it to have the right set of features.

But if we simply change the existing model definition, this will break
existing machines:

- Today, it would break on live migration, but that's slightly easy to
  fix: we have to migrate the CPUID information too, to make sure we
  won't change the CPU under the guest OS feet.

- Even if we fix live migration, simple cold migration will make the
  guest OS see a different CPU after a reboot, and that's undesirable
  too. Even if the Qemu developers disagree with me and decide that this
  is not a problem, libvirt may want to expose a more stable CPU to the
  

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

[Eduardo Habkost]

Thanks a lot for the explanations, Daniel.

Comments about specific items inline.

On Wed, Mar 07, 2012 at 02:18:28PM +, Daniel P. Berrange wrote:
  I have two main points I would like to understand/discuss:
  
  1) The relationship between libvirt's cpu_map.xml and the Qemu CPU model
 definitions.
 
 We have several areas of code in which we use CPU definitions
 
  - Reporting the host CPU definition (virsh capabilities)
  - Calculating host CPU compatibility / baseline definitions
  - Checking guest / host CPU compatibility
  - Configuring the guest CPU definition
 
 libvirt targets multiple platforms, and our CPU handling code is designed
 to be common  sharable across all the libvirt drivers, VMWare, Xen, KVM,
 LXC, etc. Obviously for container based virt, only the host side of things
 is relevant.
 
 The libvirt CPU XML definition consists of
 
  - Model name
  - Vendor name
  - zero or more feature flags added/removed.
 
 A model name is basically just an alias for a bunch of feature flags,
 so that the CPU XML definitions are a) reasonably short b) have
 some sensible default baselines.
 
 The cpu_map.xml is the database of the CPU models that libvirt
 supports. We use this database to transform the CPU definition
 from the guest XML, into the hypervisor's own format.

Understood. Makes sense.

 
 As luck would have it, the cpu_map.xml file contents match what
 QEMU has. This need not be the case though. If there is a model
 in the libvirt cpu_map.xml that QEMU doesn't know, we'll just
 pick the nearest matching QEMU cpu model  specify the fature
 flags to compensate.

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 that really implemented? I simply don't see libvirt doing that. I see
code that calls -cpu ? to list the available CPU models, but no code
calling -cpu ?dump, or parsing the Qemu CPU definition config file. I
even removed some random flags from the Nehalem model on my machine
(running Fedora 16), and no additional flags were added.


 We could go one step further and just write
 out a cpu.conf file that we load in QEMU with -loadconfig.

Sounds good. Anyway, I want to make everything configurable on the
cpudef config file configurable on the command-line too, so both options
(command-line or config file) would work.

 
 On Xen we would use the cpu_map.xml to generate the CPUID
 masks that Xen expects. Similarly for VMWare.
 
  2) How we could properly allow CPU models to be changed without breaking
 existing virtual machines?
 
 What is the scope of changes expected to CPU models ?

We already have at least four cases, affecting different fields of the
CPU definitions:

A) Adding/removing flags. Exampes:
   - When the current set of flags is simply incorrect. See commit df07ec56
 on qemu.git, where lots of flags that weren't supposed to be set
 were removed from some models.
   - When a new feature is now supported by Qemu+KVM and it's present
 on real-world CPUs, but our CPU definitions don't have the feature
 yet. e.g. x2apic, that is present on real-world Westmere CPUs but
 disabled on Qemu Westmere CPU definition.
B) Changing level for some reason. One example: Conroe, Penrym and
   Nehalem have level=2, but need to have level=4 to make CPU topology
   work, so they have to be changed.
C) Enabling/disabling or overriding specific CPUID leafs. This isn't
   even configurable on the config files today, but I plan to allow it
   to be configured, otherwise users won't be able to enable/disable
   some features that are probed by the guest by simply looking at a
   CPUID leaf (e.g. the 0xA CPUID leaf that contains PMU information).

The PMU leaf is an example where a CPU looks different by simply using a
different Qemu or kernel version, and libvirt can't control the
visibility of that feature to the guest:

- If you start a Virtual Machine using Qemu-1.0 today, with the pc-1.0
  machine-type, the PMU CPUID leaf won't be visible to the guest
  (as Qemu-1.0 doesn't support the PMU leaf).

- If you start a Virtual Machine using Qemu-1.1 in the future, using the
  pc-1.1 machine-type, with a recent kernel, the PMU CPUID leaf _will_
  be visible to the guest (as the qemu.git master branch supports it).

Up to now, it is OK because the machine-type in theory help us control
the feature, but we have a problem on this case:

- If you start a Virtual Machine using Qemu-1.1 in the future, using the
  pc-1.1 machine-type, using exactly the same command-line as above,
  but using an old kernel, the PMU CPUID leaf will _not_ be visible to
  the guest.


 
  1) Qemu and cpu_map.xml
  
  I would like to understand how cpu_map.xml is supposed to be used, and
  how it is supposed to interact with the CPU model definitions provided
  by Qemu. More precisely:
  
  1.1) Do we want to eliminate the 

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

[Eduardo Habkost]

On Wed, Mar 07, 2012 at 04:07:06PM -0700, Eric Blake wrote:
  
  (Do we have any case of capability-querying being made using QMP before
  starting any actual VM, today?)
 
 Right now, we have two levels of queries - the 'qemu -help' and 'qemu
 -device ?' output is gathered up front (we really need to patch things
 to cache that, rather than repeating it for every VM start).

That's what I feared. I was wondering if we had a better
machine-friendly interface to make some of these queries, today.

 Then we
 start qemu with -S, query QMP, all before starting the guest (qemu -S is
 in fact necessary for setting some options that cannot be set in the
 current CLI but can be set via the monitor) - but right now that is the
 only point where we query QMP capabilities.
 
 If QMP can alter the CPU model prior to the initial start of the guest,
 then that would be a sufficient interface.  But I'm worried that once we
 start qemu, even with qemu -S, that it's too late to alter the CPU model
 in use by that guest, and that libvirt should instead start querying
 these things in advance.

This is probably true, and I don't see this being changed in the near
future.

Even if we fix that for CPU initialization, there are many other
initialization steps involved that would have to be reworked to allow
all capability querying to be made to the same Qemu process that would
run the VM later.


 We definitely want a machine-parseable
 construct, so querying over QMP rather than '-cpu ?dump' sounds like it
 might be nicer, but it would also be more work to set up libvirt to do a
 dry-run query of QMP capabilities without also starting a real guest.

On the other hand, with QMP we would have a better interface that could
be used for all other queries libvirt has to run. Instead of running
Qemu multiple times for capability querying, just start a single Qemu
process and make the capability queries using QMP. I don't know if this
was discussed or considered before.


  
  But what about the features that are not available on the host CPU,
  libvirt will think it can't be enabled, but that _can_ be enabled?
  x2apic seems to be the only case today, but we may have others in the
  future.
 
 That's where having an interface to probe qemu to see what capabilities
 are possible for any given cpu model would be worthwhile, so that
 libvirt can correlate the feature sets properly.

Yes. The issue currently is that many things don't depend just on static
CPU model or machine-type definitions, libvirt has to know what
capabilities the kernel provides and Qemu will really be able to use.

It will be a long way to fix this. Some features are simply not
configurable yet, even on the command-line. They are just automatically
used by Qemu when provided by the kernel.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Thu, Mar 08, 2012 at 02:41:54PM +0100, Jiri Denemark wrote:
 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 that really implemented? I simply don't see libvirt doing that. I see
  code that calls -cpu ? to list the available CPU models, but no code
  calling -cpu ?dump, or parsing the Qemu CPU definition config file. I
  even removed some random flags from the Nehalem model on my machine
  (running Fedora 16), and no additional flags were added.
 
 Right, currently we only detect if Qemu knows requested CPU model and use
 another one if not. We should really start using something like -cpu ?dump.
 However, since qemu may decide to change parts of the model according to,
 e.g., machine type, we would need something more dynamic. Something like, hey
 Qemu, this is the machine type and CPU model we want to use, these are the
 features we want in this model, and we also want few additional features,
 please, tell us what the resulting CPU configuration is (if it is even
 possible to deliver such CPU on current host). And the result would be
 complete CPU model, which may of course be different from what the qemu's
 configuration file says. We could then use the result to update domain XML (in
 a way similar to how we handle machine types) so that we can guarantee the
 guest will always see the same CPU. Once CPU is updated, we could just check
 with Qemu if it can provide such CPU and start (or refuse to start) the
 domain. Does it seem reasonable?

Absolutely.

I would even advise libvirt to refrain from using -cpu ?dump, as its
semantics are likely to change.

   We could go one step further and just write
   out a cpu.conf file that we load in QEMU with -loadconfig.
  
  Sounds good. Anyway, I want to make everything configurable on the
  cpudef config file configurable on the command-line too, so both options
  (command-line or config file) would work.
 
 I'd be afraid of hitting the command line length limit if we specified all CPU
 details in it :-)

True. I am already afraid of hitting the command-line length limit with
Qemu as-is right now.  ;-)


  So, it looks like either I am missing something on my tests or libvirt
  is _not_ probing the Qemu CPU model definitions to make sure libvirt
  gets all the features it expects.
  
  Also, I would like to ask if you have suggestions to implement
  the equivalent of -cpu ?dump in a more friendly and extensible way.
  Would a QMP command be a good alternative? Would a command-line option
  with json output be good enough?
 
 I quite like the possible solution Anthony (or perhaps someone else) suggested
 some time ago (it may however be biased by my memory): qemu could provide a
 command line option that would take QMP command(s) and the result would be QMP
 response on stdout. We could use this interface for all kinds of probes with
 easily parsed output.

This is another case where command-line limits could be hit, isn't it?
Reading QMP commands from a normal chardev (a socket, or even stdio) is
already available, we just need to make sure the query QMP without ever
initializing a machine use-case is working and really supported by
Qemu.

  So, about the above: the cases where libvirt thinks a feature is
  available but Qemu knows it is not available are sort-of OK today,
  because Qemu would simply refuse to start and an error message would be
  returned to the user.
 
 Really? In my experience qemu just ignored the feature it didn't know about
 without any error message and started the domain happily. It might be because
 libvirt doesn't use anything like -cpu ...,check or whatever is needed to make
 it fail. However, I think we should fix it.

Correct, I was assuming that 'enforce' was being used. I forgot that
libvirt doesn't use it today.

I really think libvirt should be using 'enforce', the only problem is
that there may be cases where an existing VM was working (but with a
result unpredictable by by libvirt), and with 'enforce' it would stop
working. This is very likely to happen when using the defualt qemu64
CPU model, that has some AMD-only CPUID:8000_h bits set, but
everybody probably expects it to work on Intel CPU hosts too.

 
  But what about the features that are not available on the host CPU,
  libvirt will think it can't be enabled, but that _can_ be enabled?
  x2apic seems to be the only case today, but we may have others in the
  future.
 
 I think qemu could tell us about those features during the probe phase (my
 first paragraph) and we would either use them with policy='force' or something
 similar.

Yes, that's the conclusion I was trying to reach: we really need better
CPU feature probing.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https

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

[Eduardo Habkost]

Resurrecting an old thread:

I didn't see any clear conclusion in this thread (this is why I am
resurrecting it), except that many were arguing that libvirt should
simply copy and/or generate the CPU model definitions from Qemu. I
really don't think it's reasonable to expect that.

On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote:
 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
 -nodefconfig because we need to control the ABI presented to a guest OS and we
 don't want any configuration file that can contain lots of things including
 device definitions to be read by qemu. However, we would really like the new
 CPU models to be understood by qemu even if used through libvirt. What would
 be the best way to solve this?
 
 I suspect this could have been already discussed in the past but obviously a
 workable solution was either not found or just not implemented.

So, our problem today is basically:

A) libvirt uses -nodefconfig;
B) -nodefconfig makes Qemu not load the config file containing the CPU
   model definitions; and
C) libvirt expects the full CPU model list from Qemu to be available.

Those three expectations can't be fulfilled at the same time. So, we
have to break one of the expectations above. That means:

- Breaking (A), that would mean libvirt wouldn't use -nodefconfig. I
  think -nodefconfig _has_ a point, even if it doesn't do much today, so
  I think we can drop this possibility.

- Breaking (B), that means loading the CPU model definitions anyway
  when using -nodefconfig.
  
  I am inclined for this option: the list of CPU model defs are a list
  of CPU templates, not actual virtual machine configuration. The fact
  that the CPU templates are stored in an external file instead of
  hardcoded inside the Qemu source code is just an implementation
  detail. A more detailed explanation is below.

- Breaking (C), that means libvirt would simply not have the existing
  CPU model definitions available for its use. This is what happens
  today.

  The problem with this solution is: if we are spending lots of efforts
  defining properly all those CPU definition templates, we should allow
  the upper layers to reuse them, instead of forcing them to duplicate
  work and maintain their own copies and deal with exactly the same
  problems we had to deal inside Qemu.

This is related to the argument that CPU definitions are part of
machine-types. Machine-types are a mechanism to allow new guest-visible
features to be added to a virtual machine without waiting until libvirt
can handle the details of that feature. You just choose a newer
machine-type, and the new features are going to be enabled, even if
libvirt doesn't know anything about it.

When libvirt starts to model some details of some feature, we can let it
probe for them, so it knows what's exactly being exposed to a guest.
But while these details are not modelled by libvirt, the only way we can
let the user enjoy new features as they are available is using
machine-types. And to make this work, machine-types details can't be
disabled using -nodefconfig.

Complementing what Gleb said at that time:

On Sun, Dec 18, 2011 at 11:58:16AM +0200, Gleb Natapov wrote:
  Ideally libvirt would just write out a config file with the CPU
  that was configured in libvirt and pass -readconfig 
  /var/lib/libvirt/qemu/guestcpu.conf
  That way libvirt can configure CPU models without regard for
  what the particular QEMU version might have in its config.
  
 And how libvirt would know that particular QEMU/kvm version can create
 this CPU. Managing cpuid shouldn't be libvirt busyness.

Even if managing CPUID bits is libvirt business on some specific cases,
this is not true for _all_ CPU details.

I don't think that the libvirt internal model of CPU features will be
ever complete (and maybe it even shouldn't be). There will be always
some feature that libvirt don't know anything about, and _that_ is what
we have to model inside the Qemu CPU definitions and/or inside
machine-type definitions--I don't think we even have a choice.

We can make it easier to change and probe for the existing CPU
definitions and features, in case libvirt wants to deal with some
details, but we can't expect libvirt to be able to configure every
single detail about the CPU.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Fri, Mar 09, 2012 at 03:15:26PM -0600, Anthony Liguori wrote:
 On 03/09/2012 03:04 PM, Daniel P. Berrange wrote:
 On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote:
 Resurrecting an old thread:
 
 I didn't see any clear conclusion in this thread (this is why I am
 resurrecting it), except that many were arguing that libvirt should
 simply copy and/or generate the CPU model definitions from Qemu. I
 really don't think it's reasonable to expect that.
 
 On Thu, Dec 15, 2011 at 03:54:15PM +0100, Jiri Denemark wrote:
 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
 -nodefconfig because we need to control the ABI presented to a guest OS 
 and we
 don't want any configuration file that can contain lots of things including
 device definitions to be read by qemu. However, we would really like the 
 new
 CPU models to be understood by qemu even if used through libvirt. What 
 would
 be the best way to solve this?
 
 I suspect this could have been already discussed in the past but obviously 
 a
 workable solution was either not found or just not implemented.
 
 So, our problem today is basically:
 
 A) libvirt uses -nodefconfig;
 B) -nodefconfig makes Qemu not load the config file containing the CPU
 model definitions; and
 C) libvirt expects the full CPU model list from Qemu to be available.
 
 I could have sworn we had this discussion a year ago or so, and had decided
 that the default CPU models would be in something like 
 /usr/share/qemu/cpu-x86_64.conf
 and loaded regardless of the -nodefconfig setting. 
 /etc/qemu/target-x86_64.conf
 would be solely for end user configuration changes, not for QEMU builtin
 defaults.
 
 But looking at the code in QEMU, it doesn't seem we ever implemented this ?
 
 I don't remember that discussion and really don't think I agree with the 
 conclusion.
 
 If libvirt wants to define CPU models on their own, they can.  If
 libvirt wants to use the user's definitions, don't use -nodefconfig.
 
 CPU models aren't a QEMU concept.  The reason it's in the
 configuration file is to allow a user to add their own as they see
 fit.  There is no right model names. It's strictly a policy.

Honestly, I don't think every single detail of CPU definitions should be
considered user-provided configuration, the cpudefs are a low-level
definitions of known-to-work combinations of CPUID bits, not a proper
way for a user (or even a upper layer such as libvirt) to configure a
CPU from scratch.

At least a set of sane defaults to be used as base should be part of
what defines a machine type. If we don't do that, we will be unable to
fix bugs on those CPU definitions without having to tell users to edit
their config files, and libvirt users won't be able to use any new CPU
feature until support for them is implemented on libvirt.

And we would confuse two sets of users: 1) the ones that are using old
cpudefs but don't understand why new features aren't available even on
newer machine-types (and will have to read the Intel or AMD developer
manuals to understand how to enable the feature); 2) the ones that get
their config files upgraded automatically and don't understand why they
are getting a different virtual machine after the upgrade, even when
using an older machine-type.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Sat, Mar 10, 2012 at 12:42:46PM +, Daniel P. Berrange wrote:
  
  I could have sworn we had this discussion a year ago or so, and had decided
  that the default CPU models would be in something like 
  /usr/share/qemu/cpu-x86_64.conf
  and loaded regardless of the -nodefconfig setting. 
  /etc/qemu/target-x86_64.conf
  would be solely for end user configuration changes, not for QEMU builtin
  defaults.
  
  But looking at the code in QEMU, it doesn't seem we ever implemented this ?
 
 Arrrgggh. It seems this was implemented as a patch in RHEL-6 qemu RPMs but,
 contrary to our normal RHEL development practice, it was not based on
 a cherry-pick of an upstream patch :-(
 
 For sake of reference, I'm attaching the two patches from the RHEL6 source
 RPM that do what I'm describing
 
 NB, I'm not neccessarily advocating these patches for upstream. I still
 maintain that libvirt should write out a config file containing the
 exact CPU model description it desires and specify that with -readconfig.
 The end result would be identical from QEMU's POV and it would avoid
 playing games with QEMU's config loading code.

I agree that libvirt should just write the config somewhere. The problem
here is to define: 1) what information should be mandatory on that
config data; 2) who should be responsible to test and maintain sane
defaults (and where should they be maintained).

The current cpudef definitions are simply too low-level to require it to
be written from scratch. Lots of testing have to be done to make sure we
have working combinations of CPUID bits defined, so they can be used as
defaults or templates. Not facilitating reuse of those tested
defauls/templates by libvirt is duplication of efforts.

Really, if we expect libvirt to define all the CPU bits from scratch on
a config file, we could as well just expect libvirt to open /dev/kvm
itself and call the all CPUID setup ioctl()s itself. That's how
low-level some of the cpudef bits are.

(Also, there are additional low-level bits that really have to be
maintained somewhere, just to have sane defaults. Currently many CPUID
leafs are exposed to the guest without letting the user control them,
and worse: without keeping stability of guest-visible bits when
upgrading Qemu or the host kernel. And that's what machine-types are
for: to have sane defaults to be used as base.)

Let me give you a practical example: I had a bug report about improper
CPU topology information[1]. After investigating it, I have found out
that the level cpudef field is too low; CPU core topology information
is provided on CPUID leaf 4, and most of the Intel CPU models on Qemu
have level=2 today (I don't know why). So, Qemu is responsible for
exposing CPU topology information set using '-smp' to the guest OS, but
libvirt would have to be responsible for choosing a proper level value
that makes that information visible to the guest. We can _allow_ libvirt
to fiddle with these low-level bits, of course, but requiring every
management layer to build this low-level information from scratch is
just a recipe to waste developer time.

(And I really hope that there's no plan to require all those low-level
bits to appear as-is on the libvirt XML definitions. Because that would
require users to read the Intel 64 and IA-32 Architectures Software
Developer's Manual, or the AMD64 Architecture Programmer's Manual and
BIOS and Kernel Developer's Guides, just to understand why something is
not working on his Virtual Machine.)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=689665

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
 On 03/11/2012 08:27 AM, Gleb Natapov wrote:
 On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote:
 Let's step back here.
 
 Why are you writing these patches?  It's probably not because you
 have a desire to say -cpu Westmere when you run QEMU on your laptop.
 I'd wager to say that no human has ever done that or that if they
 had, they did so by accident because they read documentation and
 thought they had to.

No, it's because libvirt doesn't handle all the tiny small details
involved in specifying a CPU. All libvirty knows about are a set of CPU
flag bits, but it knows nothing about 'level', 'family', and 'xlevel',
but we would like to allow it to expose a Westmere-like CPU to the
guest.

libvirt does know how to use the Westmere CPU model today, if it is not
disabled by -nodefconfig. The interface it uses for probing has
deficiencies, but it works right now.


 Humans probably do one of two things: 1) no cpu option or 2) -cpu host.
 
 And both are not optimal. Actually both are bad. First one because
 default cpu is very conservative and the second because there is no
 guaranty that guest will continue to work after qemu or kernel upgrade.
 
 Let me elaborate about the later. Suppose host CPU has kill_guest
 feature and at the time a guest was installed it was not implemented by
 kvm. Since it was not implemented by kvm it was not present in vcpu
 during installation and the guest didn't install workaround kill_guest
 module. Now unsuspecting user upgrades the kernel and tries to restart
 the guest and fails. He writes angry letter to qemu-devel and is asked to
 reinstall his guest and move along.
 
 -cpu best wouldn't solve this.  You need a read/write configuration
 file where QEMU probes the available CPU and records it to be used
 for the lifetime of the VM.

If the CPU records are used for probing, this is yet another reason they
are not configuration, but defaults/templates to be used to build the
actual configuration.

IMHO, having to generate an opaque config file based on the results of
probing is poor interface design, for humans _and_ for machines. If we
have any bug on the probing, or on the data used as base for the
probing, or on the config generation, it will be impossible to deploy a
fix for the users.

This is why machine-types exist: you have the ability to implement
probing and/or sane defaults, but at the same time you can change the
probing behavior or the set of defaults without breaking existing
machines. This way, the config file contains only what the user really
wanted to configure, not some complex and opaque result of a probing
process.

Tthe fact that we have a _set_ of CPU definitions to choose from (or to
use as input for probing) instead of a single default CPU definition
that the user can change is a sign that that the cpudefs are _not_ user
configuration, but just templates/defaults.


[...]
 This discussion isn't about whether QEMU should have a Westmere
 processor definition.  In fact, I think I already applied that patch.
 
 It's a discussion about how we handle this up and down the stack.

Agreed on this point.

 
 The question is who should define and manage CPU compatibility.
 Right now QEMU does to a certain degree, libvirt discards this and
 does it's own thing, and VDSM/ovirt-engine assume that we're
 providing something and has built a UI around it.

libvirt doesn't discard this. If it just discarded this and properly
defined its own models, I wouldn't even have (re-)started this thread.

(Well, maybe I would have started a similar thread arguing that we are
wasting time working on equivalent known-to-work CPU model definitions
on Qemu and libvirt. Today we don't waste time doing it because libvirt
currently expects -nodefconfig to not disable the existing default
models).

 
 What I'm proposing we consider: have VDSM manage CPU definitions in
 order to provide a specific user experience in ovirt-engine.

I don't disagree completely with that. The problem is defining what's
CPU definitions. The current cpudef semantics is simply too low level,
it impacts other features that are _already_ managed by Qemu. Let me try
to enumerate:

- Some CPUID leafs are defined based on -smp;
- Some CPUID leafs depend on kernel capabilities;
- The availability of some CPUID leafs depend on some features
  being enabled or not, but they are simply not exposed if a proper
  'level' value is set.

We could have two approaches here: we can define some details of CPU
definitions as not configurable and others as must-be configurable,
and force management layer to agree with us about what should be
configurable or not.

Or, we could simply define that a sane set of CPU definitions are part
of a machine-type, and let managment to reconfigure parts of it if
desired, but do not force it to configure it if not needed.

 
 We would continue to have Westmere/etc in QEMU exposed as part of the
 user 

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

[Eduardo Habkost]

On Sun, Mar 11, 2012 at 10:41:32AM -0500, Anthony Liguori wrote:
 On 03/11/2012 10:12 AM, Gleb Natapov wrote:
 On Sun, Mar 11, 2012 at 09:16:49AM -0500, Anthony Liguori wrote:
 If libvirt assumes anything about what kvm actually supports it is
 working only by sheer luck.
 
 Well the simple answer for libvirt is don't use -nodefconfig and
 then it can reuse the CPU definitions (including any that the user
 adds).
 CPU models should be usable even with -nodefconfig. CPU model is more
 like device. By -cpu Nehalem I am saying I want Nehalem device in my
 machine.
 
 Let's say we moved CPU definitions to /usr/share/qemu/cpu-models.xml.
 
 Obviously, we'd want a command line option to be able to change that
 location so we'd introduce -cpu-models PATH.
 
 But we want all of our command line options to be settable by the
 global configuration file so we would have a cpu-model=PATH to the
 configuration file.
 
 But why hard code a path when we can just set the default path in the
 configuration file so let's avoid hard coding and just put
 cpu-models=/usr/share/qemu/cpu-models.xml in the default
 configuration file.

We wouldn't do the above.

-nodefconfig should disable the loading of files on /etc, but it
shouldn't disable loading internal non-configurable data that we just
happened to choose to store outside the qemu binary because it makes
development easier.

Really, the requirement of a default configuration file is a problem
by itself. Qemu should not require a default configuration file to work,
and it shouldn't require users to copy the default configuration file to
change options from the default.

Doing this would make it impossible to deploy fixes to users if we evern
find out that the default configuration file had a serious bug. What if
a bug in our default configuration file has a serious security
implication?

 
 But now when libvirt uses -nodefconfig, those models go away.
 -nodefconfig means start QEMU in the most minimal state possible.
 You get what you pay for if you use it.
 
 We'll have the same problem with machine configuration files.  At
 some point in time, -nodefconfig will make machine models disappear.

It shouldn't. Machine-types are defaults to be used as base, they are
not user-provided configuration. And the fact that we decided to store
some data outside of the Qemu binary is orthogonal the design decisions
in the Qemu command-line and configuration interface.

As I said previously, requiring generation of opaque config files (and
copy the default config file and change it is included on my
definition of generation of opaque config files) is poor design, IMO.
I bet this even has an entry in some design anti-pattern catalog
somewhere.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Mon, Mar 12, 2012 at 03:15:32PM +0200, Gleb Natapov wrote:
 On Mon, Mar 12, 2012 at 01:04:19PM +, Daniel P. Berrange wrote:
  On Mon, Mar 12, 2012 at 09:52:27AM -0300, Eduardo Habkost wrote:
   On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
On 03/11/2012 08:27 AM, Gleb Natapov wrote:
On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote:
Let's step back here.

Why are you writing these patches?  It's probably not because you
have a desire to say -cpu Westmere when you run QEMU on your laptop.
I'd wager to say that no human has ever done that or that if they
had, they did so by accident because they read documentation and
thought they had to.
   
   No, it's because libvirt doesn't handle all the tiny small details
   involved in specifying a CPU. All libvirty knows about are a set of CPU
   flag bits, but it knows nothing about 'level', 'family', and 'xlevel',
   but we would like to allow it to expose a Westmere-like CPU to the
   guest.
  
  This is easily fixable in libvirt - so for the point of going discussion,
  IMHO, we can assume libvirt will support level, family, xlevel, etc.
  
 And fill in all cpuid leafs by querying /dev/kvm when needed or, if TCG
 is used, replicating QEMU logic? And since QEMU should be usable without
 libvirt the same logic should be implemented in QEMU anyway.

To implement this properly, libvirt will need a proper probing interface
to know what exactly is available and can be enabled. I plan to
implement that.

I am have no problem in giving to libvirt the power to shoot itself in
the foot. I believe libvirt developers can handle that. I have a problem
with requiring every user (human or machine) to handle a weapon that can
shoot their foot (that means, requiring the user to write the CPU model
definition from scratch, or requiring the user to blindly copypaste the
default config file).

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Mon, Mar 12, 2012 at 09:48:11AM -0500, Anthony Liguori wrote:
 On 03/11/2012 11:16 AM, Gleb Natapov wrote:
 On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote:
 On 03/11/2012 09:56 AM, Gleb Natapov wrote:
 On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
 -cpu best wouldn't solve this.  You need a read/write configuration
 file where QEMU probes the available CPU and records it to be used
 for the lifetime of the VM.
 That what I thought too, but this shouldn't be the case (Avi's idea).
 We need two things: 1) CPU model config should be per machine type.
 2) QEMU should refuse to start if it cannot create cpu exactly as
 specified by model config.
 
 This would either mean:
 
 A. pc-1.1 uses -cpu best with a fixed mask for 1.1
 
 B. pc-1.1 hardcodes Westmere or some other family
 
 This would mean neither A nor B. May be it wasn't clear but I didn't talk
 about -cpu best above. I am talking about any CPU model with fixed meaning
 (not host or best which are host cpu dependant). Lets take Nehalem for
 example (just to move from Westmere :)). Currently it has level=2. Eduardo
 wants to fix it to be 11, but old guests, installed with -cpu Nehalem,
 should see the same CPU exactly. How do you do it? Have different
 Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11).
 Lets get back to Westmere. It actually has level=11, but that's only
 expose another problem. Kernel 3.3 and qemu-1.1 combo will support
 architectural PMU which is exposed in cpuid leaf 10. We do not want
 guests installed with -cpu Westmere and qemu-1.0 to see architectural
 PMU after upgrade. How do you do it? Have different Westmere definitions
 for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens
 if you'll try to run qemu-1.1 -cpu Westmere on Kernel  3.3 (without
 PMU support)? Qemu will fail to start.
 
 So, you're essentially proposing that -cpu Westmere becomes a machine
 option and that we let the machines interpret it as they see fit?
 
 So --machine pc-1.0,cpu=Westmere would result in something different
 than --machine pc-1.1,cpu=Westmere?

Exactly.

 That's something pretty different than what we're doing today.  I
 think that we would have a single CPUX86 object and that part of the
 pc initialization process was to create an appropriately configured
 CPUx86 object.

Yes, that's different from what we're doing today, and it has to be
fixed.

(And, BTW, I'm really worried about your proposal that machine-types
would suddenly disappear when using -nodefconfig in case we decide to
move machine-type data to an external file one day. Design decisions
aside, this would break an interface that management tools already have
today.)

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas Färber wrote:
 Am 11.03.2012 17:16, schrieb Gleb Natapov:
  On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote:
  On 03/11/2012 09:56 AM, Gleb Natapov wrote:
  On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
  -cpu best wouldn't solve this.  You need a read/write configuration
  file where QEMU probes the available CPU and records it to be used
  for the lifetime of the VM.
  That what I thought too, but this shouldn't be the case (Avi's idea).
  We need two things: 1) CPU model config should be per machine type.
  2) QEMU should refuse to start if it cannot create cpu exactly as
  specified by model config.
 
  This would either mean:
 
  A. pc-1.1 uses -cpu best with a fixed mask for 1.1
 
  B. pc-1.1 hardcodes Westmere or some other family
 
  This would mean neither A nor B. May be it wasn't clear but I didn't talk
  about -cpu best above. I am talking about any CPU model with fixed meaning
  (not host or best which are host cpu dependant). Lets take Nehalem for
  example (just to move from Westmere :)). Currently it has level=2. Eduardo
  wants to fix it to be 11, but old guests, installed with -cpu Nehalem,
  should see the same CPU exactly. How do you do it? Have different
  Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11).
  Lets get back to Westmere. It actually has level=11, but that's only
  expose another problem. Kernel 3.3 and qemu-1.1 combo will support
  architectural PMU which is exposed in cpuid leaf 10. We do not want
  guests installed with -cpu Westmere and qemu-1.0 to see architectural
  PMU after upgrade. How do you do it? Have different Westmere definitions
  for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens
  if you'll try to run qemu-1.1 -cpu Westmere on Kernel  3.3 (without
  PMU support)? Qemu will fail to start.
 
 This sounds pretty much like what Liu Jinsong and Jan are discussing in
 the TSC thread on qemu-devel. (cc'ing)

I'll look for that thread. Thanks!

 
 IMO interpreting an explicit -cpu parameter depending on -M would be
 wrong. Changing the default CPU based on -M is fine with me. For an
 explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the
 user gets what the user asks for, without unexpected magic.

It is not unexpected magic. It would be a documented mechanism:
-cpu Nehalem-1.0 and -cpu Nehalem-1.1 would have the same meaning
every time, with any machine-type, but -cpu Nehalem would be an alias,
whose meaning depends on the machine-type.

Otherwise we would be stuck with a broken Nehalem model forever, and
we don't want that.

 Note that on my qom-cpu-wip branch [1] (that I hope to have cleaned up
 and sent out by tomorrow), all built-in CPUs become statically
 registered QOM types. The external definitions that get passed in via
 -cpudef become dynamically registered QOM types; I took care to allow
 overriding existing classes with the specified -cpudef fields (but
 untested). Setting family, level, etc. for -cpu is done on the X86CPU
 object instance. [2]
 What I don't have yet are QOM properties to set the fields from, e.g.,
 machine code, but those should be fairly easy to add.

Sounds interesting. I will have to take a look at the code to understand how it
affects what's being discussed in this thread.

 
 Andreas
 
 [1] http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-wip
 
 [2]
 http://repo.or.cz/w/qemu/afaerber.git/commit/8a6ede101a2722b790489989f21cad38d3e41fb5
 
 -- 
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Mon, Mar 12, 2012 at 06:41:06PM +0100, Andreas Färber wrote:
 Am 12.03.2012 17:50, schrieb Eduardo Habkost:
  On Mon, Mar 12, 2012 at 04:49:47PM +0100, Andreas Färber wrote:
[...]
  IMO interpreting an explicit -cpu parameter depending on -M would be
  wrong. Changing the default CPU based on -M is fine with me. For an
  explicit argument we would need Westmere-1.0 analog to pc-1.0. Then the
  user gets what the user asks for, without unexpected magic.
  
  It is not unexpected magic. It would be a documented mechanism:
  -cpu Nehalem-1.0 and -cpu Nehalem-1.1 would have the same meaning
  every time, with any machine-type, but -cpu Nehalem would be an alias,
  whose meaning depends on the machine-type.
  
  Otherwise we would be stuck with a broken Nehalem model forever, and
  we don't want that.
 
 Not quite what I meant: In light of QOM we should be able to instantiate
 a CPU based on its name and optional parameters IMO. No dependency on
 the machine, please. An alias sure, but if the user explicitly says -cpu
 Nehalem then on 1.1 it should always be an alias to Nehalem-1.1 whether
 the machine is -M pc-0.15 or pc. If no -cpu was specified by the user,
 then choosing a default of Nehalem-1.0 for pc-1.0 is fine. Just trying
 to keep separate things separate here.

As Gleb explained, things aren't really separated:
qemu-1.1 -M pc-1.0 -cpu Nehalem should result in the same machine as
qemu-1.0 -cpu Nehalem, no difference should be visible to the guest.
simply make incompatible changes.

 
 Also keep in mind linux-user. There's no concept of a machine there, but
 there's a cpu_copy() function used for forking that tries to re-create
 the CPU based on its model. So currently cpu_*_init(env-cpu_model_str)
 needs to be able to recreate an identical CPU through the central code
 path, without access to a QEMUMachine.

So just translate the CPU alias given to -cpu to the true CPU model
name as soon as possible, at the command-line-handling code, so the rest
of the code always see the true CPU model name.

After all, the need to make the aliases is a command-line interface
compatibility problem, so it makes sense to handle this at the
command-line-handling code.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

So, trying to summarize what was discussed in the call:

On Mon, Mar 12, 2012 at 10:08:10AM -0300, Eduardo Habkost wrote:
  Let's say we moved CPU definitions to /usr/share/qemu/cpu-models.xml.
  
  Obviously, we'd want a command line option to be able to change that
  location so we'd introduce -cpu-models PATH.
  
  But we want all of our command line options to be settable by the
  global configuration file so we would have a cpu-model=PATH to the
  configuration file.
  
  But why hard code a path when we can just set the default path in the
  configuration file so let's avoid hard coding and just put
  cpu-models=/usr/share/qemu/cpu-models.xml in the default
  configuration file.
 
 We wouldn't do the above.
 
 -nodefconfig should disable the loading of files on /etc, but it
 shouldn't disable loading internal non-configurable data that we just
 happened to choose to store outside the qemu binary because it makes
 development easier.

The statement above is the one not fulfilled by the compromise solution:
-nodefconfig would really disable the loading of files on /usr/share.

 
 Really, the requirement of a default configuration file is a problem
 by itself. Qemu should not require a default configuration file to work,
 and it shouldn't require users to copy the default configuration file to
 change options from the default.

The statement above is only partly true. The default configuration file
would be still needed, but if defaults are stored on /usr/share, I will
be happy with it.

My main problem was with the need to _copy_ or edit a non-trivial
default config file. If the not-often-edited defaults/templates are
easily found on /usr/share to be used with -readconfig, I will be happy
with this solution, even if -nodefconfig disable the files on
/usr/share.

 
 Doing this would make it impossible to deploy fixes to users if we evern
 find out that the default configuration file had a serious bug. What if
 a bug in our default configuration file has a serious security
 implication?

The answer to this is: if the broken templates/defaults are on
/usr/share, it would be easy to deploy the fix.

So, the compromise solution is:

- We can move some configuration data (especially defaults/templates)
  to /usr/share (machine-types and CPU models could go there). This
  way we can easily deploy fixes to the defaults, if necessary.
- To reuse Qemu models, or machine-types, and not define everything from
  scratch, libvirt will have to use something like:
  -nodefconfig -readconfig /usr/share/qemu/cpu-models-x86.conf


(the item below is not something discussed on the call, just something I
want to add)

To make this work better, we can allow users (humans or machines) to
extend CPU models on the config file, instead of having to define
everything from scratch. So, on /etc (or on a libvirt-generated config)
we could have something like:

=
[cpu]
base_cpudef = Nehalem
add_features = vmx
=

Then, as long as /usr/share/cpu-models-x86.conf is loaded, the user will
be able to reuse the Nehalem CPU model provided by Qemu.

 
  
  But now when libvirt uses -nodefconfig, those models go away.
  -nodefconfig means start QEMU in the most minimal state possible.
  You get what you pay for if you use it.
  
  We'll have the same problem with machine configuration files.  At
  some point in time, -nodefconfig will make machine models disappear.
 
 It shouldn't. Machine-types are defaults to be used as base, they are
 not user-provided configuration. And the fact that we decided to store
 some data outside of the Qemu binary is orthogonal the design decisions
 in the Qemu command-line and configuration interface.

So, this problem is solved if the defaults are easily found on
/usr/share.

We still have the backwards compatibility problem for pc-1.0, pc-1.1,
and so on. But that can be discussed later, when we actually move
machine-types to somewhere outside .c files.

 
 As I said previously, requiring generation of opaque config files (and
 copy the default config file and change it is included on my
 definition of generation of opaque config files) is poor design, IMO.
 I bet this even has an entry in some design anti-pattern catalog
 somewhere.

This problem is also solved if the defaults are deployed on /usr/share
and just reused/included by the config files on /etc.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

I added a summary of the changes I am planning, at:
http://wiki.qemu.org/Features/CPUModels#Current_Issues_and_proposed_changes

I'm sure I forgot lots of details, so feel free to send me questions and
suggestions, or even edit the wiki page directly.


On Fri, Mar 09, 2012 at 05:56:52PM -0300, Eduardo Habkost wrote:
 Resurrecting an old thread:
 
[...]

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Thu, Mar 22, 2012 at 11:32:44AM +0200, Gleb Natapov wrote:
 On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote:
  So, trying to summarize what was discussed in the call:
  
  On Mon, Mar 12, 2012 at 10:08:10AM -0300, Eduardo Habkost wrote:
Let's say we moved CPU definitions to /usr/share/qemu/cpu-models.xml.

Obviously, we'd want a command line option to be able to change that
location so we'd introduce -cpu-models PATH.

But we want all of our command line options to be settable by the
global configuration file so we would have a cpu-model=PATH to the
configuration file.

But why hard code a path when we can just set the default path in the
configuration file so let's avoid hard coding and just put
cpu-models=/usr/share/qemu/cpu-models.xml in the default
configuration file.
   
   We wouldn't do the above.
   
   -nodefconfig should disable the loading of files on /etc, but it
   shouldn't disable loading internal non-configurable data that we just
   happened to choose to store outside the qemu binary because it makes
   development easier.
  
  The statement above is the one not fulfilled by the compromise solution:
  -nodefconfig would really disable the loading of files on /usr/share.
  
 What does this mean? Will -nodefconfig disable loading of bios.bin,
 option roms, keymaps?

Correcting myself: loading of _config_ files on /usr/share. ROM images
are opaque data to be presented to the guest somehow, just like a disk
image or kernel binary. But maybe keymaps will become configuration
someday, I really don't know.


   
   Doing this would make it impossible to deploy fixes to users if we evern
   find out that the default configuration file had a serious bug. What if
   a bug in our default configuration file has a serious security
   implication?
  
  The answer to this is: if the broken templates/defaults are on
  /usr/share, it would be easy to deploy the fix.
  
  So, the compromise solution is:
  
  - We can move some configuration data (especially defaults/templates)
to /usr/share (machine-types and CPU models could go there). This
way we can easily deploy fixes to the defaults, if necessary.
  - To reuse Qemu models, or machine-types, and not define everything from
scratch, libvirt will have to use something like:
-nodefconfig -readconfig /usr/share/qemu/cpu-models-x86.conf
  
 cpu-models-x86.conf is not a configuration file. It is hardware
 description file. QEMU should not lose capability just because you run
 it with -nodefconfig. -nodefconfig means that QEMU does not create
 machine for you, but all parts needed to create a machine that would have
 been created without -nodefconfig are still present. Not been able to
 create Nehalem CPU after specifying -nodefconfig is the same as not been
 able to create virtio-net i.e the bug.


The current design direction Qemu seems to be following is different
from that: hardware description is also considered configuration just
like actual machine configuration. Anthony, please correct me if I am
wrong.


What you propose is to have two levels of configuration (or
descriptions, or whatever we call it):

1) Hardware descriptions (or templates, or models, whatever we call it),
   that are not editable by the user (and not disabled by -nodefconfig).
   This may include CPU models, hardware emulation implemented in
   another language, machine-types, and other stuff that is part of
   what Qemu always provides.
2) Actual machine configuration file, that is configurable and editable
   by the user, and normally loaded from /etc on from the command-line.

The only problem is: the Qemu design simply doesn't have this
distinction today (well, it _has_, the only difference is that today
item (1) is almost completely coded inside tables in .c files). So if we
want to go in that direction we have to agree this will be part of the
Qemu design.

I am not strongly inclined either way. Both approaches look good to me,
we just have to decide where we are going, because we're are in this
weird position todady because we never decided it explicitly, libvirt
expected one thing, and we implemented something else.

On the one hand I think the two-layer design gives us more freedom to
move stuff outside .c files and change implementation details, and fits
how we have been doing until today with machine types and built-in CPU
models, keymaps, etc.

On the other hand, I think not having this distinction between machine
configuration and hardware description may be a good thing.

For example: today there are two different ways of enabling a feature on
a CPU: defining a new model, and adding a flag to -cpu. And I think
this asymmetry shouldn't be there: you just need a good system to define
a CPU, a good set of defaults/templates, and a good system to base your
configuration on those defaults/teampltes, no need to have two separate
CPU definition languages. Also, we wouldn't have to code

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

[Eduardo Habkost]

On Thu, Mar 22, 2012 at 11:37:39AM -0500, Anthony Liguori wrote:
 On 03/22/2012 04:32 AM, Gleb Natapov wrote:
 On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote:
 So, this problem is solved if the defaults are easily found on
 /usr/share.
 
 What problem is solved and why are we mixing machine configuration files
 and cpu configuration files? They are different and should be treated
 differently. -nodefconfig exists only because there is not machine
 configuration files currently. With machine configuration files
 libvirt does not need -nodefconfig because it can create its own machine
 file and make QEMU use it. So specifying machine file on QEMU's command
 line implies -nodefconfig. The option itself loses its meaning and can be
 dropped.
 
 No, -nodefconfig means no default config.
 
 As with many projects, we can have *some* configuration required.
 
 The default configure should have a:
 
 [system]
 readconfig=@SYSCONFDIR@/cpu-models-x86_64.cfg

Not @SYSCONFDIR@, but @DATADIR@. CPU models belong to /usr/share because
they aren't meant to be changed by the user (I think I already explained
why: because we have to be able to deploy fixes to them).

 
 Stanza by default.  If libvirt wants to reuse this, they can use
 -readconfig if they use -nodefconfig.

You are just repeating how you believe it should work based on the
premise that cpudefs are configuration. We're discussing/questioning
this exact premise, here, and I would really appreciate to hear why the
model Gleb is proposing is not valid.

More precisely, this part:

 cpu-models-x86.conf is not a configuration file. It is hardware
 description file. QEMU should not lose capability just because you run
 it with -nodefconfig. -nodefconfig means that QEMU does not create
 machine for you, but all parts needed to create a machine that would have
 been created without -nodefconfig are still present. Not been able to
 create Nehalem CPU after specifying -nodefconfig is the same as not been
 able to create virtio-net i.e the bug.

And the related points Gleb mentioned further in this thread.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Sun, Mar 25, 2012 at 12:19:13PM +0200, Gleb Natapov wrote:
  (That's why I said that perhaps keymaps could become configuration
  someday. Because maybe they can be converted to a key=value model
  relatively easily)
  
 Such whole sale approach is harmful since it starts to affect design
 decisions. So now if it seams logical to move something outside the code
 one can decide against it just because it will become configuration
 due to that design.

This is one point I agree completely with.

There's no reason to couple the decision to move something to an
external file with making changes to the Qemu external interfaces.

We should be able to gradually move things to be data without breaking
the expectations of libvirt at the same time. We must be able to make a
gradual design change, where we first move data to an external file
without making that change visible to the outside, then slowly try to
make it part of the user-visible configuration (that means making
externally visible interface changes, something that has to be made much
more carefully than just moving internal data around). Anthony seems
to be simply rejecting the possibility of doing this gradual change[1].

[1] I still need to read this whole thread, so sorry if I am wrong.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Mon, Mar 26, 2012 at 02:03:21PM +0200, Gleb Natapov wrote:
 On Mon, Mar 26, 2012 at 01:59:05PM +0200, Avi Kivity wrote:
  On 03/26/2012 01:24 PM, Jiri Denemark wrote:
   ...
 The command line becomes unstable if you use -nodefconfig.

-no-user-config solves this but I fully expect libvirt would continue 
to use 
-nodefconfig.
  
   Libvirt uses -nodefaults -nodefconfig because it wants to fully control 
   how
   the virtual machine will look like (mainly in terms of devices). In other
   words, we don't want any devices to just magically appear without libvirt
   knowing about them. -nodefaults gets rid of default devices that are built
   directly in qemu. Since users can set any devices or command line options
   (such as enable-kvm) into qemu configuration files in @SYSCONFDIR@, we 
   need to
   avoid reading those files as well. Hence we use -nodefconfig. However, we
   would still like qemu to read CPU definitions, machine types, etc. once 
   they
   become externally loaded configuration (or however we decide to call it). 
   That
   said, when CPU definitions are moved into @DATADIR@, and -no-user-config 
   is
   introduced, I don't see any reason for libvirt to keep using -nodefconfig.

ACK.

  
   I actually like
   -no-user-config
   more than
   -nodefconfig -readconfig @DATADIR@/...
   since it would avoid additional magic to detect what files libvirt should
   explicitly pass to -readconfig but basically any approach that would 
   allow us
   to do read files only from @DATADIR@ is much better than what we have with
   -nodefconfig now.
  
  That's how I see it as well.
  
 +1
 
 except that instead of -no-user-config we can do what most other
 programs do. If config file is specified during invocation default one
 is not used. After implementing -no-user-config (or similar) we can drop
 -nodefconfig entirely since its only user will be gone it its semantics
 is not clear.

Awesome. It looks like we have a solution now? Anthony, do you agree
with that? Daniel, it looks good for you?

It looks like in the end, no one will ever use -nodefconfig because it's
optimizing for a use-case that nobody cares about. Maybe I'm wrong and
somebody somewhere will use -nodefconfig, maybe Anthony has a specific
use-case or specific tools in mind, I don't know. But personally I will
probably simply ignore the existence of -nodefconfig because it is
absolutely useless for me and for libvirt.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Sun, Mar 25, 2012 at 01:11:04PM -0500, Anthony Liguori wrote:
 On 03/25/2012 10:40 AM, Avi Kivity wrote:
 On 03/25/2012 05:26 PM, Anthony Liguori wrote:
 Put the emphasis around *configuration*.
 
 
 So how about:
 
 1) Load ['@SYSCONFDIR@/qemu/qemu.cfg',
 '@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
   '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
 
 2) system-@ARCH@.cfg will contain:
 
 [system]
 readconfig=@DATADIR@/target-@a...@-cpus.cfg
 readconfig=@DATADIR@/target-@a...@-machine.cfg
 
 3) -nodefconfig will not load any configuration files from DATADIR or
 SYSCONFDIR.  -no-user-config will not load any configuration files
 from SYSCONFDIR.
 
 What, more options?
 
 Okay, we can just drop -no-user-config and then if a management tool
 wants to do the equivalent, they can do -nodefconfig + '-readconfig
 @DATADIR@/system-@ARCH@.cfg'.  I'm equally happy with that :-)

I actually prefer -no-user-config, because it gives Qemu freedom to add
more stuff to the outside if needed, but without requiring more
-readconfig options (or -read-something-else options, if we create them)
to be added in the future.

For example, if one day we move machine-types to external files, libvirt
wouldn't have to be changed to add Yet Another -readconfig argument to
make the machine-types available for use. If Qemu moves some device
implementation to external modules, they won't suddenly go away for
users of -no-user-config. The list of possible changes that would break
compatibility for -nodefconfig users but no -no-user-config users is
large.

[...]
 I don't think -nodefconfig (as defined) is usable, since there is no way
 for the user to tell what it means short of reading those files.
 
 *if the user doesn't know specifics about this QEMU version.
 
 You make the assumption that all users are going to throw arbitrary
 options at arbitrary QEMU versions.  That's certainly an important
 use-case but it's not the only one.

Well, you make the assumption that somebody will every want to use
-nodefconfig the way you want to define it. I don't think nobody will
ever use it if we defined it that way, but that's OK with me. I will
simply ignore the existence of -nodefconfig from now on.  :-)

[...]
 #define westmere blah is not configuration, otherwise the meaning of
 configuration will drift over time.
 
 -cpu blah is, of course.
 
 It's the same mechanism, but the above would create two classes of
 default configuration files and then it becomes a question of how
 they're used.
 
 Confused.
 
 We don't have a formal concept of -read-definition-config and
 -read-configuration-config
 
 There's no easy or obvious way to create such a concept either nor do
 I think the distinction is meaningful to users.

The distinction _is_ meaningful to libvirt, that's what started this
thread.

[...]
 The file defines westmere as an alias for a grab bag of options.
 Whether it's loaded or not is immaterial, unless someone uses one
 of the
 names within.
 
 But you would agree, a management tool should be able to control
 whether class factories get loaded, right?
 
 No, why?  But perhaps I don't entirely get what you mean by class
 factories.
 
 Aren't they just implementations of
 
  virtual Device *new_instance(...) = 0?
 
 if so, why not load them?
 
 No, a class factory creates a new type of class.  -cpudef will
 ultimately call type_register() to create a new QOM visible type.
  From a management tools perspective, the type is no different than a
 built-in type.
 
 Exactly.  The types are no different, so there's no reason to
 discriminate against types that happen to live in qemu-provided data
 files vs. qemu code.  They aren't instantiated, so we lose nothing by
 creating the factories (just so long as the factories aren't
 mass-producing objects).
 
 At some point, I'd like to have type modules that are shared objects.
 I'd like QEMU to start with almost no builtin types and allow the
 user to configure which modules get loaded.
 
 In the long term, I'd like QEMU to be a small, robust core with the
 vast majority of code relegated to modules with the user ultimately
 in control of module loading.
 
 Yes, I'd want some module autoloading system but there should always
 be a way to launch QEMU without loading any modules and then load a
 very specific set of modules (as defined by the user).

And libvirt needs a way to keep module autoloading enabled while
disabling the loading of files from /etc.

 
 You can imagine this being useful for something like Common Criteria 
 certifications.

No problem, except that this is not the use-case libvirt has. If you
want -nodefconfig to mean that, that's OK. But we need an option to just
disable the loading of files from /etc, but keeping loading the default
non-user-configurable modules that usually are available (be it CPU
models, machine-types, external modules, whatever), and doesn't keep
changing meaning on every minor release.

[...]
 -nodefconfig = create an empty machine, 

[libvirt] [PATCH 3/5] move list of default config files to an array

[Eduardo Habkost]

More files will be added to the list, with additional attributes, later.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |   25 -
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 152cbbb..62332e9 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -112,20 +112,27 @@ const uint32_t arch_type = QEMU_ARCH;
 #endif
 
 
+static struct defconfig_file {
+const char *filename;
+} default_config_files[] = {
+{ CONFIG_QEMU_CONFDIR /qemu.conf },
+{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf },
+{ NULL }, /* end of list */
+};
+
+
 int qemu_read_default_config_files(void)
 {
 int ret;
-
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
-if (ret  0  ret != -ENOENT) {
-return ret;
-}
+struct defconfig_file *f;
 
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf);
-if (ret  0  ret != -ENOENT) {
-return ret;
+for (f = default_config_files; f-filename; f++) {
+ret = qemu_read_config_file(f-filename);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
 }
-
+
 return 0;
 }
 
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 0/5] -no-user-config option, move CPU models to /usr/share

[Eduardo Habkost]

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 file, with the CPU models we currently have on Qemu.

Reference to previous discussion:
 - http://marc.info/?l=qemu-develm=133278877315665

This series depends on the following:
  Subject: [PATCH v5 00/14] configure: --with-confsuffix option
  Message-Id: 1334778950-18660-1-git-send-email-ehabk...@redhat.com


Eduardo Habkost (5):
  move code to read default config files to a separate function
  eliminate arch_config_name variable
  move list of default config files to an array
  implement -no-user-config command-line option
  move CPU definitions to /usr/share/qemu/cpus-x86_64.conf

 Makefile |   12 +++-
 arch_init.c  |   31 -
 arch_init.h  |6 +-
 qemu-options.hx  |   16 -
 sysconfigs/target/cpus-x86_64.conf   |  128 ++
 sysconfigs/target/target-x86_64.conf |  128 --
 vl.c |   14 ++--
 7 files changed, 190 insertions(+), 145 deletions(-)
 create mode 100644 sysconfigs/target/cpus-x86_64.conf

-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 1/5] move code to read default config files to a separate function

[Eduardo Habkost]

Function added to arch_init.c because it depends on arch-specific
settings.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |   18 ++
 arch_init.h |4 
 vl.c|   10 ++
 3 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 9a35aee..4008115 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -112,6 +112,24 @@ const uint32_t arch_type = QEMU_ARCH;
 #define ALL_EQ(v1, v2) ((v1) == (v2))
 #endif
 
+
+int qemu_read_default_config_files(void)
+{
+int ret;
+
+ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
+
+ret = qemu_read_config_file(arch_config_name);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
+
+return 0;
+}
+
 static int is_dup_page(uint8_t *page)
 {
 VECTYPE *p = (VECTYPE *)page;
diff --git a/arch_init.h b/arch_init.h
index 828256c..329faf7 100644
--- a/arch_init.h
+++ b/arch_init.h
@@ -32,4 +32,8 @@ int tcg_available(void);
 int kvm_available(void);
 int xen_available(void);
 
+/* Read default Qemu config files
+ */
+int qemu_read_default_config_files(void);
+
 #endif
diff --git a/vl.c b/vl.c
index ae91a8a..1e5e593 100644
--- a/vl.c
+++ b/vl.c
@@ -2354,14 +2354,8 @@ int main(int argc, char **argv, char **envp)
 
 if (defconfig) {
 int ret;
-
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
-if (ret  0  ret != -ENOENT) {
-exit(1);
-}
-
-ret = qemu_read_config_file(arch_config_name);
-if (ret  0  ret != -ENOENT) {
+ret = qemu_read_default_config_files();
+if (ret  0) {
 exit(1);
 }
 }
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 4/5] implement -no-user-config command-line option

[Eduardo Habkost]

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |   10 +++---
 arch_init.h |2 +-
 qemu-options.hx |   16 +---
 vl.c|6 +-
 4 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 62332e9..c5fc00f 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -114,19 +114,23 @@ const uint32_t arch_type = QEMU_ARCH;
 
 static struct defconfig_file {
 const char *filename;
+/* If non-zero, this is a user config file (disabled by -no-user-config) */
+int userconfig;
 } default_config_files[] = {
-{ CONFIG_QEMU_CONFDIR /qemu.conf },
-{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf },
+{ CONFIG_QEMU_CONFDIR /qemu.conf,   1 },
+{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf, 1 },
 { NULL }, /* end of list */
 };
 
 
-int qemu_read_default_config_files(void)
+int qemu_read_default_config_files(int userconfig)
 {
 int ret;
 struct defconfig_file *f;
 
 for (f = default_config_files; f-filename; f++) {
+if (!userconfig  f-userconfig)
+continue;
 ret = qemu_read_config_file(f-filename);
 if (ret  0  ret != -ENOENT) {
 return ret;
diff --git a/arch_init.h b/arch_init.h
index 495871b..07510cf 100644
--- a/arch_init.h
+++ b/arch_init.h
@@ -32,6 +32,6 @@ int xen_available(void);
 
 /* Read default Qemu config files
  */
-int qemu_read_default_config_files(void);
+int qemu_read_default_config_files(int userconfig);
 
 #endif
diff --git a/qemu-options.hx b/qemu-options.hx
index a169792..7d0b054 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2685,9 +2685,19 @@ DEF(nodefconfig, 0, QEMU_OPTION_nodefconfig,
 STEXI
 @item -nodefconfig
 @findex -nodefconfig
-Normally QEMU loads a configuration file from @var{sysconfdir}/qemu.conf and
-@var{sysconfdir}/target-@var{ARCH}.conf on startup.  The @code{-nodefconfig}
-option will prevent QEMU from loading these configuration files at startup.
+Normally QEMU loads configuration files from @var{sysconfdir} and 
@var{datadir} at startup.
+The @code{-nodefconfig} option will prevent QEMU from loading any of those 
config files.
+ETEXI
+DEF(no-user-config, 0, QEMU_OPTION_nouserconfig,
+-no-user-config\n
+do not load user-provided config files at startup\n,
+QEMU_ARCH_ALL)
+STEXI
+@item -no-user-config
+@findex -no-user-config
+The @code{-no-user-config} option makes QEMU not load any of the user-provided
+config files on @var{sysconfdir}, but won't make it skip the QEMU-provided 
config
+files from @var{datadir}.
 ETEXI
 DEF(trace, HAS_ARG, QEMU_OPTION_trace,
 -trace [events=file][,file=file]\n
diff --git a/vl.c b/vl.c
index 1e5e593..347dadd 100644
--- a/vl.c
+++ b/vl.c
@@ -2280,6 +2280,7 @@ int main(int argc, char **argv, char **envp)
 int show_vnc_port = 0;
 #endif
 int defconfig = 1;
+int userconfig = 1;
 const char *log_mask = NULL;
 const char *log_file = NULL;
 GMemVTable mem_trace = {
@@ -2348,13 +2349,16 @@ int main(int argc, char **argv, char **envp)
 case QEMU_OPTION_nodefconfig:
 defconfig=0;
 break;
+case QEMU_OPTION_nouserconfig:
+userconfig=0;
+break;
 }
 }
 }
 
 if (defconfig) {
 int ret;
-ret = qemu_read_default_config_files();
+ret = qemu_read_default_config_files(userconfig);
 if (ret  0) {
 exit(1);
 }
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 2/5] eliminate arch_config_name variable

[Eduardo Habkost]

Not needed anymore, as the code that uses the variable is already inside
arch_init.c.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |3 +--
 arch_init.h |2 --
 2 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 4008115..152cbbb 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -54,7 +54,6 @@ int graphic_height = 600;
 int graphic_depth = 15;
 #endif
 
-const char arch_config_name[] = CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf;
 
 #if defined(TARGET_ALPHA)
 #define QEMU_ARCH QEMU_ARCH_ALPHA
@@ -122,7 +121,7 @@ int qemu_read_default_config_files(void)
 return ret;
 }
 
-ret = qemu_read_config_file(arch_config_name);
+ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf);
 if (ret  0  ret != -ENOENT) {
 return ret;
 }
diff --git a/arch_init.h b/arch_init.h
index 329faf7..495871b 100644
--- a/arch_init.h
+++ b/arch_init.h
@@ -1,8 +1,6 @@
 #ifndef QEMU_ARCH_INIT_H
 #define QEMU_ARCH_INIT_H
 
-extern const char arch_config_name[];
-
 enum {
 QEMU_ARCH_ALL = -1,
 QEMU_ARCH_ALPHA = 1,
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 5/5] move CPU definitions to /usr/share/qemu/cpus-x86_64.conf

[Eduardo Habkost]

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 Makefile |   12 +++-
 arch_init.c  |1 +
 sysconfigs/target/cpus-x86_64.conf   |  128 ++
 sysconfigs/target/target-x86_64.conf |  128 --
 4 files changed, 138 insertions(+), 131 deletions(-)
 create mode 100644 sysconfigs/target/cpus-x86_64.conf

diff --git a/Makefile b/Makefile
index 4f43793..6c20f27 100644
--- a/Makefile
+++ b/Makefile
@@ -280,11 +280,18 @@ ifdef CONFIG_VIRTFS
$(INSTALL_DIR) $(DESTDIR)$(mandir)/man1
$(INSTALL_DATA) fsdev/virtfs-proxy-helper.1 $(DESTDIR)$(mandir)/man1
 endif
-install-sysconfig:
+
+install-datadir:
+   $(INSTALL_DIR) $(DESTDIR)$(qemu_datadir)
+
+install-confdir:
$(INSTALL_DIR) $(DESTDIR)$(qemu_confdir)
+
+install-sysconfig: install-datadir install-confdir
$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf 
$(DESTDIR)$(qemu_confdir)
+   $(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/cpus-x86_64.conf 
$(DESTDIR)$(qemu_datadir)
 
-install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig
+install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig install-datadir
$(INSTALL_DIR) $(DESTDIR)$(bindir)
 ifneq ($(TOOLS),)
$(INSTALL_PROG) $(STRIP_OPT) $(TOOLS) $(DESTDIR)$(bindir)
@@ -294,7 +301,6 @@ ifneq ($(HELPERS-y),)
$(INSTALL_PROG) $(STRIP_OPT) $(HELPERS-y) $(DESTDIR)$(libexecdir)
 endif
 ifneq ($(BLOBS),)
-   $(INSTALL_DIR) $(DESTDIR)$(qemu_datadir)
set -e; for x in $(BLOBS); do \
$(INSTALL_DATA) $(SRC_PATH)/pc-bios/$$x 
$(DESTDIR)$(qemu_datadir); \
done
diff --git a/arch_init.c b/arch_init.c
index c5fc00f..1d7f43d 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -117,6 +117,7 @@ static struct defconfig_file {
 /* If non-zero, this is a user config file (disabled by -no-user-config) */
 int userconfig;
 } default_config_files[] = {
+{ CONFIG_QEMU_DATADIR /cpus- TARGET_ARCH .conf,   0 },
 { CONFIG_QEMU_CONFDIR /qemu.conf,   1 },
 { CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf, 1 },
 { NULL }, /* end of list */
diff --git a/sysconfigs/target/cpus-x86_64.conf 
b/sysconfigs/target/cpus-x86_64.conf
new file mode 100644
index 000..cee0ea9
--- /dev/null
+++ b/sysconfigs/target/cpus-x86_64.conf
@@ -0,0 +1,128 @@
+# x86 CPU MODELS
+
+[cpudef]
+   name = Conroe
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = ssse3 sse3
+   extfeature_edx = i64 xd syscall
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Celeron_4x0 (Conroe/Merom Class Core 2)
+
+[cpudef]
+   name = Penryn
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 xd syscall
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Core 2 Duo P9xxx (Penryn Class Core 2)
+
+[cpudef]
+   name = Nehalem
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = popcnt sse4.2 sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 syscall xd
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Core i7 9xx (Nehalem Class Core i7)
+
+[cpudef]
+   name = Westmere
+   level = 11
+   vendor = GenuineIntel
+   family = 6
+   model = 44
+   stepping = 1
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = aes popcnt sse4.2 sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 syscall xd
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Westmere E56xx/L56xx/X56xx (Nehalem-C)
+
+[cpudef]
+   name = SandyBridge
+   level = 0xd
+   vendor = GenuineIntel
+   family = 6
+   model = 42
+   stepping = 1
+   feature_edx =  sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = avx xsave aes tsc-deadline popcnt x2apic sse4.2 sse4.1 cx16 
ssse3 pclmulqdq sse3
+   extfeature_edx = i64 rdtscp nx syscall 
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Xeon E312xx (Sandy Bridge)
+
+[cpudef]
+   name = Opteron_G1
+   level = 5
+   vendor = AuthenticAMD
+   family = 15
+   model = 6
+   stepping = 1
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = sse3
+   extfeature_edx = lm fxsr mmx nx pse36 pat cmov mca pge mtrr syscall apic 
cx8 mce pae msr tsc pse de fpu
+   extfeature_ecx

[libvirt] [PATCH qemu 2/6] eliminate arch_config_name variable

[Eduardo Habkost]

Not needed anymore, as the code that uses the variable is already inside
arch_init.c.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |3 +--
 arch_init.h |2 --
 2 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 4008115..152cbbb 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -54,7 +54,6 @@ int graphic_height = 600;
 int graphic_depth = 15;
 #endif
 
-const char arch_config_name[] = CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf;
 
 #if defined(TARGET_ALPHA)
 #define QEMU_ARCH QEMU_ARCH_ALPHA
@@ -122,7 +121,7 @@ int qemu_read_default_config_files(void)
 return ret;
 }
 
-ret = qemu_read_config_file(arch_config_name);
+ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf);
 if (ret  0  ret != -ENOENT) {
 return ret;
 }
diff --git a/arch_init.h b/arch_init.h
index 828256c..c7cb94a 100644
--- a/arch_init.h
+++ b/arch_init.h
@@ -1,8 +1,6 @@
 #ifndef QEMU_ARCH_INIT_H
 #define QEMU_ARCH_INIT_H
 
-extern const char arch_config_name[];
-
 enum {
 QEMU_ARCH_ALL = -1,
 QEMU_ARCH_ALPHA = 1,
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 3/6] move list of default config files to an array

[Eduardo Habkost]

More files will be added to the list, with additional attributes, later.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |   25 -
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 152cbbb..62332e9 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -112,20 +112,27 @@ const uint32_t arch_type = QEMU_ARCH;
 #endif
 
 
+static struct defconfig_file {
+const char *filename;
+} default_config_files[] = {
+{ CONFIG_QEMU_CONFDIR /qemu.conf },
+{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf },
+{ NULL }, /* end of list */
+};
+
+
 int qemu_read_default_config_files(void)
 {
 int ret;
-
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
-if (ret  0  ret != -ENOENT) {
-return ret;
-}
+struct defconfig_file *f;
 
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf);
-if (ret  0  ret != -ENOENT) {
-return ret;
+for (f = default_config_files; f-filename; f++) {
+ret = qemu_read_config_file(f-filename);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
 }
-
+
 return 0;
 }
 
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 6/6] move CPU definitions to /usr/share/qemu/cpus-x86_64.conf (v2)

[Eduardo Habkost]

Changes v1 - v2:
 - userconfig variable is now bool, not int

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 Makefile |   12 +++-
 arch_init.c  |1 +
 sysconfigs/target/cpus-x86_64.conf   |  128 ++
 sysconfigs/target/target-x86_64.conf |  128 --
 4 files changed, 138 insertions(+), 131 deletions(-)
 create mode 100644 sysconfigs/target/cpus-x86_64.conf

diff --git a/Makefile b/Makefile
index 4f43793..6c20f27 100644
--- a/Makefile
+++ b/Makefile
@@ -280,11 +280,18 @@ ifdef CONFIG_VIRTFS
$(INSTALL_DIR) $(DESTDIR)$(mandir)/man1
$(INSTALL_DATA) fsdev/virtfs-proxy-helper.1 $(DESTDIR)$(mandir)/man1
 endif
-install-sysconfig:
+
+install-datadir:
+   $(INSTALL_DIR) $(DESTDIR)$(qemu_datadir)
+
+install-confdir:
$(INSTALL_DIR) $(DESTDIR)$(qemu_confdir)
+
+install-sysconfig: install-datadir install-confdir
$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf 
$(DESTDIR)$(qemu_confdir)
+   $(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/cpus-x86_64.conf 
$(DESTDIR)$(qemu_datadir)
 
-install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig
+install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig install-datadir
$(INSTALL_DIR) $(DESTDIR)$(bindir)
 ifneq ($(TOOLS),)
$(INSTALL_PROG) $(STRIP_OPT) $(TOOLS) $(DESTDIR)$(bindir)
@@ -294,7 +301,6 @@ ifneq ($(HELPERS-y),)
$(INSTALL_PROG) $(STRIP_OPT) $(HELPERS-y) $(DESTDIR)$(libexecdir)
 endif
 ifneq ($(BLOBS),)
-   $(INSTALL_DIR) $(DESTDIR)$(qemu_datadir)
set -e; for x in $(BLOBS); do \
$(INSTALL_DATA) $(SRC_PATH)/pc-bios/$$x 
$(DESTDIR)$(qemu_datadir); \
done
diff --git a/arch_init.c b/arch_init.c
index 996baba..988adca 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -117,6 +117,7 @@ static struct defconfig_file {
 /* Indicates it is an user config file (disabled by -no-user-config) */
 bool userconfig;
 } default_config_files[] = {
+{ CONFIG_QEMU_DATADIR /cpus- TARGET_ARCH .conf,  false },
 { CONFIG_QEMU_CONFDIR /qemu.conf,   true },
 { CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf, true },
 { NULL }, /* end of list */
diff --git a/sysconfigs/target/cpus-x86_64.conf 
b/sysconfigs/target/cpus-x86_64.conf
new file mode 100644
index 000..cee0ea9
--- /dev/null
+++ b/sysconfigs/target/cpus-x86_64.conf
@@ -0,0 +1,128 @@
+# x86 CPU MODELS
+
+[cpudef]
+   name = Conroe
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = ssse3 sse3
+   extfeature_edx = i64 xd syscall
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Celeron_4x0 (Conroe/Merom Class Core 2)
+
+[cpudef]
+   name = Penryn
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 xd syscall
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Core 2 Duo P9xxx (Penryn Class Core 2)
+
+[cpudef]
+   name = Nehalem
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = popcnt sse4.2 sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 syscall xd
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Core i7 9xx (Nehalem Class Core i7)
+
+[cpudef]
+   name = Westmere
+   level = 11
+   vendor = GenuineIntel
+   family = 6
+   model = 44
+   stepping = 1
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = aes popcnt sse4.2 sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 syscall xd
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Westmere E56xx/L56xx/X56xx (Nehalem-C)
+
+[cpudef]
+   name = SandyBridge
+   level = 0xd
+   vendor = GenuineIntel
+   family = 6
+   model = 42
+   stepping = 1
+   feature_edx =  sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = avx xsave aes tsc-deadline popcnt x2apic sse4.2 sse4.1 cx16 
ssse3 pclmulqdq sse3
+   extfeature_edx = i64 rdtscp nx syscall 
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Xeon E312xx (Sandy Bridge)
+
+[cpudef]
+   name = Opteron_G1
+   level = 5
+   vendor = AuthenticAMD
+   family = 15
+   model = 6
+   stepping = 1
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = sse3
+   extfeature_edx = lm fxsr mmx nx pse36 pat cmov mca pge mtrr

[libvirt] [PATCH qemu 4/6] vl.c: change 'defconfig' variable to bool

[Eduardo Habkost]

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 vl.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index 1e5e593..a4f4676 100644
--- a/vl.c
+++ b/vl.c
@@ -2279,7 +2279,7 @@ int main(int argc, char **argv, char **envp)
 #ifdef CONFIG_VNC
 int show_vnc_port = 0;
 #endif
-int defconfig = 1;
+int defconfig = true;
 const char *log_mask = NULL;
 const char *log_file = NULL;
 GMemVTable mem_trace = {
@@ -2346,7 +2346,7 @@ int main(int argc, char **argv, char **envp)
 popt = lookup_opt(argc, argv, optarg, optind);
 switch (popt-index) {
 case QEMU_OPTION_nodefconfig:
-defconfig=0;
+defconfig = false;
 break;
 }
 }
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 1/6] move code to read default config files to a separate function (v2)

[Eduardo Habkost]

Function added to arch_init.c because it depends on arch-specific
settings.

Changes v1 - v2:
 - Move qemu_read_default_config_file() prototype to qemu-config.h

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c   |   18 ++
 qemu-config.h |4 
 vl.c  |   10 ++
 3 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 9a35aee..4008115 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -112,6 +112,24 @@ const uint32_t arch_type = QEMU_ARCH;
 #define ALL_EQ(v1, v2) ((v1) == (v2))
 #endif
 
+
+int qemu_read_default_config_files(void)
+{
+int ret;
+
+ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
+
+ret = qemu_read_config_file(arch_config_name);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
+
+return 0;
+}
+
 static int is_dup_page(uint8_t *page)
 {
 VECTYPE *p = (VECTYPE *)page;
diff --git a/qemu-config.h b/qemu-config.h
index 20d707f..ff934a1 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -16,4 +16,8 @@ int qemu_config_parse(FILE *fp, QemuOptsList **lists, const 
char *fname);
 
 int qemu_read_config_file(const char *filename);
 
+/* Read default Qemu config files
+ */
+int qemu_read_default_config_files(void);
+
 #endif /* QEMU_CONFIG_H */
diff --git a/vl.c b/vl.c
index ae91a8a..1e5e593 100644
--- a/vl.c
+++ b/vl.c
@@ -2354,14 +2354,8 @@ int main(int argc, char **argv, char **envp)
 
 if (defconfig) {
 int ret;
-
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
-if (ret  0  ret != -ENOENT) {
-exit(1);
-}
-
-ret = qemu_read_config_file(arch_config_name);
-if (ret  0  ret != -ENOENT) {
+ret = qemu_read_default_config_files();
+if (ret  0) {
 exit(1);
 }
 }
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 5/6] implement -no-user-config command-line option (v2)

[Eduardo Habkost]

Changes v1 - v2:
 - Change 'userconfig' field/variables to bool instead of int
 - Coding style change

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |   11 ---
 qemu-config.h   |2 +-
 qemu-options.hx |   16 +---
 vl.c|6 +-
 4 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 62332e9..996baba 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -114,19 +114,24 @@ const uint32_t arch_type = QEMU_ARCH;
 
 static struct defconfig_file {
 const char *filename;
+/* Indicates it is an user config file (disabled by -no-user-config) */
+bool userconfig;
 } default_config_files[] = {
-{ CONFIG_QEMU_CONFDIR /qemu.conf },
-{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf },
+{ CONFIG_QEMU_CONFDIR /qemu.conf,   true },
+{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf, true },
 { NULL }, /* end of list */
 };
 
 
-int qemu_read_default_config_files(void)
+int qemu_read_default_config_files(bool userconfig)
 {
 int ret;
 struct defconfig_file *f;
 
 for (f = default_config_files; f-filename; f++) {
+if (!userconfig  f-userconfig) {
+continue;
+}
 ret = qemu_read_config_file(f-filename);
 if (ret  0  ret != -ENOENT) {
 return ret;
diff --git a/qemu-config.h b/qemu-config.h
index ff934a1..6d7365d 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -18,6 +18,6 @@ int qemu_read_config_file(const char *filename);
 
 /* Read default Qemu config files
  */
-int qemu_read_default_config_files(void);
+int qemu_read_default_config_files(bool userconfig);
 
 #endif /* QEMU_CONFIG_H */
diff --git a/qemu-options.hx b/qemu-options.hx
index a169792..7d0b054 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2685,9 +2685,19 @@ DEF(nodefconfig, 0, QEMU_OPTION_nodefconfig,
 STEXI
 @item -nodefconfig
 @findex -nodefconfig
-Normally QEMU loads a configuration file from @var{sysconfdir}/qemu.conf and
-@var{sysconfdir}/target-@var{ARCH}.conf on startup.  The @code{-nodefconfig}
-option will prevent QEMU from loading these configuration files at startup.
+Normally QEMU loads configuration files from @var{sysconfdir} and 
@var{datadir} at startup.
+The @code{-nodefconfig} option will prevent QEMU from loading any of those 
config files.
+ETEXI
+DEF(no-user-config, 0, QEMU_OPTION_nouserconfig,
+-no-user-config\n
+do not load user-provided config files at startup\n,
+QEMU_ARCH_ALL)
+STEXI
+@item -no-user-config
+@findex -no-user-config
+The @code{-no-user-config} option makes QEMU not load any of the user-provided
+config files on @var{sysconfdir}, but won't make it skip the QEMU-provided 
config
+files from @var{datadir}.
 ETEXI
 DEF(trace, HAS_ARG, QEMU_OPTION_trace,
 -trace [events=file][,file=file]\n
diff --git a/vl.c b/vl.c
index a4f4676..967b7e8 100644
--- a/vl.c
+++ b/vl.c
@@ -2280,6 +2280,7 @@ int main(int argc, char **argv, char **envp)
 int show_vnc_port = 0;
 #endif
 int defconfig = true;
+bool userconfig = true;
 const char *log_mask = NULL;
 const char *log_file = NULL;
 GMemVTable mem_trace = {
@@ -2348,13 +2349,16 @@ int main(int argc, char **argv, char **envp)
 case QEMU_OPTION_nodefconfig:
 defconfig = false;
 break;
+case QEMU_OPTION_nouserconfig:
+userconfig = false;
+break;
 }
 }
 }
 
 if (defconfig) {
 int ret;
-ret = qemu_read_default_config_files();
+ret = qemu_read_default_config_files(userconfig);
 if (ret  0) {
 exit(1);
 }
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu v2 0/6] -no-user-config option, move CPU models to /usr/share

[Eduardo Habkost]

Changes v1 - v2:
 - Move qemu_read_default_config_files() prototype to qemu-config.h
 - Make defconfig and userconfig variable bool
 - Coding style change

Patches 1 to 4 just move some code around, patch 5 just adds the new option
without adding any new config file. Patch 6 finally creates a /usr/share/qemu
/cpus-x86_64.conf file, with the CPU models we currently have on Qemu.

Reference to previous discussion:
 - http://marc.info/?l=qemu-develm=133278877315665


Eduardo Habkost (6):
  move code to read default config files to a separate function (v2)
  eliminate arch_config_name variable
  move list of default config files to an array
  vl.c: change 'defconfig' variable to bool
  implement -no-user-config command-line option (v2)
  move CPU definitions to /usr/share/qemu/cpus-x86_64.conf (v2)

 Makefile |   12 +++-
 arch_init.c  |   32 -
 arch_init.h  |2 -
 qemu-config.h|4 +
 qemu-options.hx  |   16 -
 sysconfigs/target/cpus-x86_64.conf   |  128 ++
 sysconfigs/target/target-x86_64.conf |  128 --
 vl.c |   18 ++---
 8 files changed, 193 insertions(+), 147 deletions(-)
 create mode 100644 sysconfigs/target/cpus-x86_64.conf

-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH qemu 4/6] vl.c: change 'defconfig' variable to bool

[Eduardo Habkost]

On Sat, Apr 28, 2012 at 07:53:41AM +, Blue Swirl wrote:
 On Tue, Apr 24, 2012 at 20:32, Eduardo Habkost ehabk...@redhat.com wrote:
  Signed-off-by: Eduardo Habkost ehabk...@redhat.com
  ---
   vl.c |    4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/vl.c b/vl.c
  index 1e5e593..a4f4676 100644
  --- a/vl.c
  +++ b/vl.c
  @@ -2279,7 +2279,7 @@ int main(int argc, char **argv, char **envp)
   #ifdef CONFIG_VNC
      int show_vnc_port = 0;
   #endif
  -    int defconfig = 1;
  +    int defconfig = true;
 
 The type is still 'int', is that intentional?

Oops! It was not, sorry. I will respin the series.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 7/6] vl.c: actually change defconfig variable to bool

[Eduardo Habkost]

I changed everything on my previous patch to change 'defconfig', but
forgot to actually change the variable data type.

As the incomplete change doesn't cause any issues or compiler warnings,
I am simply sending this additional patch instead of respinning the
whole series.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 vl.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 967b7e8..87db855 100644
--- a/vl.c
+++ b/vl.c
@@ -2279,7 +2279,7 @@ int main(int argc, char **argv, char **envp)
 #ifdef CONFIG_VNC
 int show_vnc_port = 0;
 #endif
-int defconfig = true;
+bool defconfig = true;
 bool userconfig = true;
 const char *log_mask = NULL;
 const char *log_file = NULL;
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

Anthony, isn't this going to get in for 1.1? I was expecting it to be
applied before the freeze.


On Tue, Apr 24, 2012 at 05:32:55PM -0300, Eduardo Habkost wrote:
 Changes v1 - v2:
  - Move qemu_read_default_config_files() prototype to qemu-config.h
  - Make defconfig and userconfig variable bool
  - Coding style change
 
 Patches 1 to 4 just move some code around, patch 5 just adds the new option
 without adding any new config file. Patch 6 finally creates a /usr/share/qemu
 /cpus-x86_64.conf file, with the CPU models we currently have on Qemu.
 
 Reference to previous discussion:
  - http://marc.info/?l=qemu-develm=133278877315665
 
 
 Eduardo Habkost (6):
   move code to read default config files to a separate function (v2)
   eliminate arch_config_name variable
   move list of default config files to an array
   vl.c: change 'defconfig' variable to bool
   implement -no-user-config command-line option (v2)
   move CPU definitions to /usr/share/qemu/cpus-x86_64.conf (v2)
 
  Makefile |   12 +++-
  arch_init.c  |   32 -
  arch_init.h  |2 -
  qemu-config.h|4 +
  qemu-options.hx  |   16 -
  sysconfigs/target/cpus-x86_64.conf   |  128 
 ++
  sysconfigs/target/target-x86_64.conf |  128 
 --
  vl.c |   18 ++---
  8 files changed, 193 insertions(+), 147 deletions(-)
  create mode 100644 sysconfigs/target/cpus-x86_64.conf
 
 -- 
 1.7.3.2
 

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Wed, May 02, 2012 at 04:01:55PM +0200, Andreas Färber wrote:
 Am 02.05.2012 15:50, schrieb Eduardo Habkost:
  
  Anthony, isn't this going to get in for 1.1? I was expecting it to be
  applied before the freeze.
 
 You wrote you would respin it with s/int/bool/. :)

I sent an additional patch instead of respinning (see patch 7/6 sent as
reply to this series).

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 3/6] move list of default config files to an array

[Eduardo Habkost]

More files will be added to the list, with additional attributes, later.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |   25 -
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 152cbbb..62332e9 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -112,20 +112,27 @@ const uint32_t arch_type = QEMU_ARCH;
 #endif
 
 
+static struct defconfig_file {
+const char *filename;
+} default_config_files[] = {
+{ CONFIG_QEMU_CONFDIR /qemu.conf },
+{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf },
+{ NULL }, /* end of list */
+};
+
+
 int qemu_read_default_config_files(void)
 {
 int ret;
-
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
-if (ret  0  ret != -ENOENT) {
-return ret;
-}
+struct defconfig_file *f;
 
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf);
-if (ret  0  ret != -ENOENT) {
-return ret;
+for (f = default_config_files; f-filename; f++) {
+ret = qemu_read_config_file(f-filename);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
 }
-
+
 return 0;
 }
 
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 2/6] eliminate arch_config_name variable

[Eduardo Habkost]

Not needed anymore, as the code that uses the variable is already inside
arch_init.c.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |3 +--
 arch_init.h |2 --
 2 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 4008115..152cbbb 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -54,7 +54,6 @@ int graphic_height = 600;
 int graphic_depth = 15;
 #endif
 
-const char arch_config_name[] = CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf;
 
 #if defined(TARGET_ALPHA)
 #define QEMU_ARCH QEMU_ARCH_ALPHA
@@ -122,7 +121,7 @@ int qemu_read_default_config_files(void)
 return ret;
 }
 
-ret = qemu_read_config_file(arch_config_name);
+ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /target- TARGET_ARCH 
.conf);
 if (ret  0  ret != -ENOENT) {
 return ret;
 }
diff --git a/arch_init.h b/arch_init.h
index 828256c..c7cb94a 100644
--- a/arch_init.h
+++ b/arch_init.h
@@ -1,8 +1,6 @@
 #ifndef QEMU_ARCH_INIT_H
 #define QEMU_ARCH_INIT_H
 
-extern const char arch_config_name[];
-
 enum {
 QEMU_ARCH_ALL = -1,
 QEMU_ARCH_ALPHA = 1,
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 4/6] vl.c: change 'defconfig' variable to bool (v2)

[Eduardo Habkost]

Changes v1 - v2:
 - Actually change the variable type declaration to 'bool'

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 vl.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index 1e5e593..eb3e088 100644
--- a/vl.c
+++ b/vl.c
@@ -2279,7 +2279,7 @@ int main(int argc, char **argv, char **envp)
 #ifdef CONFIG_VNC
 int show_vnc_port = 0;
 #endif
-int defconfig = 1;
+bool defconfig = true;
 const char *log_mask = NULL;
 const char *log_file = NULL;
 GMemVTable mem_trace = {
@@ -2346,7 +2346,7 @@ int main(int argc, char **argv, char **envp)
 popt = lookup_opt(argc, argv, optarg, optind);
 switch (popt-index) {
 case QEMU_OPTION_nodefconfig:
-defconfig=0;
+defconfig = false;
 break;
 }
 }
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

Changes v2 - v3:
 - Actually change 'defconfig' type declaration to bool
 - Rebase against latest qemu.git (commit 
563987d0a799f90b58a575b190a57546c335191b)

Changes v1 - v2:
 - Move qemu_read_default_config_files() prototype to qemu-config.h
 - Make defconfig and userconfig variable bool
 - Coding style change

Patches 1 to 4 just move some code around, patch 5 just adds the new option
without adding any new config file. Patch 6 finally creates a /usr/share/qemu
/cpus-x86_64.conf file, with the CPU models we currently have on Qemu.

Reference to previous discussion:
 - http://marc.info/?l=qemu-develm=133278877315665


Eduardo Habkost (6):
  move code to read default config files to a separate function (v2)
  eliminate arch_config_name variable
  move list of default config files to an array
  vl.c: change 'defconfig' variable to bool (v2)
  implement -no-user-config command-line option (v3)
  move CPU definitions to /usr/share/qemu/cpus-x86_64.conf (v2)

 Makefile |   12 +++-
 arch_init.c  |   32 -
 arch_init.h  |2 -
 qemu-config.h|4 +
 qemu-options.hx  |   16 -
 sysconfigs/target/cpus-x86_64.conf   |  128 ++
 sysconfigs/target/target-x86_64.conf |  128 --
 vl.c |   18 ++---
 8 files changed, 193 insertions(+), 147 deletions(-)
 create mode 100644 sysconfigs/target/cpus-x86_64.conf

-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 5/6] implement -no-user-config command-line option (v3)

[Eduardo Habkost]

Changes v2 - v3:
 - Rebase against latest qemu.git

Changes v1 - v2:
 - Change 'userconfig' field/variables to bool instead of int
 - Coding style change

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c |   11 ---
 qemu-config.h   |2 +-
 qemu-options.hx |   16 +---
 vl.c|6 +-
 4 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 62332e9..996baba 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -114,19 +114,24 @@ const uint32_t arch_type = QEMU_ARCH;
 
 static struct defconfig_file {
 const char *filename;
+/* Indicates it is an user config file (disabled by -no-user-config) */
+bool userconfig;
 } default_config_files[] = {
-{ CONFIG_QEMU_CONFDIR /qemu.conf },
-{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf },
+{ CONFIG_QEMU_CONFDIR /qemu.conf,   true },
+{ CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf, true },
 { NULL }, /* end of list */
 };
 
 
-int qemu_read_default_config_files(void)
+int qemu_read_default_config_files(bool userconfig)
 {
 int ret;
 struct defconfig_file *f;
 
 for (f = default_config_files; f-filename; f++) {
+if (!userconfig  f-userconfig) {
+continue;
+}
 ret = qemu_read_config_file(f-filename);
 if (ret  0  ret != -ENOENT) {
 return ret;
diff --git a/qemu-config.h b/qemu-config.h
index ff934a1..6d7365d 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -18,6 +18,6 @@ int qemu_read_config_file(const char *filename);
 
 /* Read default Qemu config files
  */
-int qemu_read_default_config_files(void);
+int qemu_read_default_config_files(bool userconfig);
 
 #endif /* QEMU_CONFIG_H */
diff --git a/qemu-options.hx b/qemu-options.hx
index a169792..7d0b054 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2685,9 +2685,19 @@ DEF(nodefconfig, 0, QEMU_OPTION_nodefconfig,
 STEXI
 @item -nodefconfig
 @findex -nodefconfig
-Normally QEMU loads a configuration file from @var{sysconfdir}/qemu.conf and
-@var{sysconfdir}/target-@var{ARCH}.conf on startup.  The @code{-nodefconfig}
-option will prevent QEMU from loading these configuration files at startup.
+Normally QEMU loads configuration files from @var{sysconfdir} and 
@var{datadir} at startup.
+The @code{-nodefconfig} option will prevent QEMU from loading any of those 
config files.
+ETEXI
+DEF(no-user-config, 0, QEMU_OPTION_nouserconfig,
+-no-user-config\n
+do not load user-provided config files at startup\n,
+QEMU_ARCH_ALL)
+STEXI
+@item -no-user-config
+@findex -no-user-config
+The @code{-no-user-config} option makes QEMU not load any of the user-provided
+config files on @var{sysconfdir}, but won't make it skip the QEMU-provided 
config
+files from @var{datadir}.
 ETEXI
 DEF(trace, HAS_ARG, QEMU_OPTION_trace,
 -trace [events=file][,file=file]\n
diff --git a/vl.c b/vl.c
index eb3e088..87db855 100644
--- a/vl.c
+++ b/vl.c
@@ -2280,6 +2280,7 @@ int main(int argc, char **argv, char **envp)
 int show_vnc_port = 0;
 #endif
 bool defconfig = true;
+bool userconfig = true;
 const char *log_mask = NULL;
 const char *log_file = NULL;
 GMemVTable mem_trace = {
@@ -2348,13 +2349,16 @@ int main(int argc, char **argv, char **envp)
 case QEMU_OPTION_nodefconfig:
 defconfig = false;
 break;
+case QEMU_OPTION_nouserconfig:
+userconfig = false;
+break;
 }
 }
 }
 
 if (defconfig) {
 int ret;
-ret = qemu_read_default_config_files();
+ret = qemu_read_default_config_files(userconfig);
 if (ret  0) {
 exit(1);
 }
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qemu 6/6] move CPU definitions to /usr/share/qemu/cpus-x86_64.conf (v2)

[Eduardo Habkost]

Changes v1 - v2:
 - userconfig variable is now bool, not int

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 Makefile |   12 +++-
 arch_init.c  |1 +
 sysconfigs/target/cpus-x86_64.conf   |  128 ++
 sysconfigs/target/target-x86_64.conf |  128 --
 4 files changed, 138 insertions(+), 131 deletions(-)
 create mode 100644 sysconfigs/target/cpus-x86_64.conf

diff --git a/Makefile b/Makefile
index 08ec758..9b7a85e 100644
--- a/Makefile
+++ b/Makefile
@@ -281,11 +281,18 @@ ifdef CONFIG_VIRTFS
$(INSTALL_DIR) $(DESTDIR)$(mandir)/man1
$(INSTALL_DATA) fsdev/virtfs-proxy-helper.1 $(DESTDIR)$(mandir)/man1
 endif
-install-sysconfig:
+
+install-datadir:
+   $(INSTALL_DIR) $(DESTDIR)$(qemu_datadir)
+
+install-confdir:
$(INSTALL_DIR) $(DESTDIR)$(qemu_confdir)
+
+install-sysconfig: install-datadir install-confdir
$(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/target-x86_64.conf 
$(DESTDIR)$(qemu_confdir)
+   $(INSTALL_DATA) $(SRC_PATH)/sysconfigs/target/cpus-x86_64.conf 
$(DESTDIR)$(qemu_datadir)
 
-install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig
+install: all $(if $(BUILD_DOCS),install-doc) install-sysconfig install-datadir
$(INSTALL_DIR) $(DESTDIR)$(bindir)
 ifneq ($(TOOLS),)
$(INSTALL_PROG) $(STRIP_OPT) $(TOOLS) $(DESTDIR)$(bindir)
@@ -295,7 +302,6 @@ ifneq ($(HELPERS-y),)
$(INSTALL_PROG) $(STRIP_OPT) $(HELPERS-y) $(DESTDIR)$(libexecdir)
 endif
 ifneq ($(BLOBS),)
-   $(INSTALL_DIR) $(DESTDIR)$(qemu_datadir)
set -e; for x in $(BLOBS); do \
$(INSTALL_DATA) $(SRC_PATH)/pc-bios/$$x 
$(DESTDIR)$(qemu_datadir); \
done
diff --git a/arch_init.c b/arch_init.c
index 996baba..988adca 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -117,6 +117,7 @@ static struct defconfig_file {
 /* Indicates it is an user config file (disabled by -no-user-config) */
 bool userconfig;
 } default_config_files[] = {
+{ CONFIG_QEMU_DATADIR /cpus- TARGET_ARCH .conf,  false },
 { CONFIG_QEMU_CONFDIR /qemu.conf,   true },
 { CONFIG_QEMU_CONFDIR /target- TARGET_ARCH .conf, true },
 { NULL }, /* end of list */
diff --git a/sysconfigs/target/cpus-x86_64.conf 
b/sysconfigs/target/cpus-x86_64.conf
new file mode 100644
index 000..cee0ea9
--- /dev/null
+++ b/sysconfigs/target/cpus-x86_64.conf
@@ -0,0 +1,128 @@
+# x86 CPU MODELS
+
+[cpudef]
+   name = Conroe
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = ssse3 sse3
+   extfeature_edx = i64 xd syscall
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Celeron_4x0 (Conroe/Merom Class Core 2)
+
+[cpudef]
+   name = Penryn
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 xd syscall
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Core 2 Duo P9xxx (Penryn Class Core 2)
+
+[cpudef]
+   name = Nehalem
+   level = 2
+   vendor = GenuineIntel
+   family = 6
+   model = 2
+   stepping = 3
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = popcnt sse4.2 sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 syscall xd
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Core i7 9xx (Nehalem Class Core i7)
+
+[cpudef]
+   name = Westmere
+   level = 11
+   vendor = GenuineIntel
+   family = 6
+   model = 44
+   stepping = 1
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = aes popcnt sse4.2 sse4.1 cx16 ssse3 sse3
+   extfeature_edx = i64 syscall xd
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Westmere E56xx/L56xx/X56xx (Nehalem-C)
+
+[cpudef]
+   name = SandyBridge
+   level = 0xd
+   vendor = GenuineIntel
+   family = 6
+   model = 42
+   stepping = 1
+   feature_edx =  sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = avx xsave aes tsc-deadline popcnt x2apic sse4.2 sse4.1 cx16 
ssse3 pclmulqdq sse3
+   extfeature_edx = i64 rdtscp nx syscall 
+   extfeature_ecx = lahf_lm
+   xlevel = 0x800A
+   model_id = Intel Xeon E312xx (Sandy Bridge)
+
+[cpudef]
+   name = Opteron_G1
+   level = 5
+   vendor = AuthenticAMD
+   family = 15
+   model = 6
+   stepping = 1
+   feature_edx = sse2 sse fxsr mmx clflush pse36 pat cmov mca pge mtrr sep 
apic cx8 mce pae msr tsc pse de fpu
+   feature_ecx = sse3
+   extfeature_edx = lm fxsr mmx nx pse36 pat cmov mca pge mtrr

[libvirt] [PATCH qemu 1/6] move code to read default config files to a separate function (v2)

[Eduardo Habkost]

Function added to arch_init.c because it depends on arch-specific
settings.

Changes v1 - v2:
 - Move qemu_read_default_config_file() prototype to qemu-config.h

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 arch_init.c   |   18 ++
 qemu-config.h |4 
 vl.c  |   10 ++
 3 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index 9a35aee..4008115 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -112,6 +112,24 @@ const uint32_t arch_type = QEMU_ARCH;
 #define ALL_EQ(v1, v2) ((v1) == (v2))
 #endif
 
+
+int qemu_read_default_config_files(void)
+{
+int ret;
+
+ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
+
+ret = qemu_read_config_file(arch_config_name);
+if (ret  0  ret != -ENOENT) {
+return ret;
+}
+
+return 0;
+}
+
 static int is_dup_page(uint8_t *page)
 {
 VECTYPE *p = (VECTYPE *)page;
diff --git a/qemu-config.h b/qemu-config.h
index 20d707f..ff934a1 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -16,4 +16,8 @@ int qemu_config_parse(FILE *fp, QemuOptsList **lists, const 
char *fname);
 
 int qemu_read_config_file(const char *filename);
 
+/* Read default Qemu config files
+ */
+int qemu_read_default_config_files(void);
+
 #endif /* QEMU_CONFIG_H */
diff --git a/vl.c b/vl.c
index ae91a8a..1e5e593 100644
--- a/vl.c
+++ b/vl.c
@@ -2354,14 +2354,8 @@ int main(int argc, char **argv, char **envp)
 
 if (defconfig) {
 int ret;
-
-ret = qemu_read_config_file(CONFIG_QEMU_CONFDIR /qemu.conf);
-if (ret  0  ret != -ENOENT) {
-exit(1);
-}
-
-ret = qemu_read_config_file(arch_config_name);
-if (ret  0  ret != -ENOENT) {
+ret = qemu_read_default_config_files();
+if (ret  0) {
 exit(1);
 }
 }
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

This allows , to be used a separator between each CPU range.  Note
that commas inside key=value command-line options have to be escaped
using ,,, so the command-line will look like:

  -numa node,cpus=A,,B,,C,,D

Note that the following format, currently used by libvirt:

  -numa nodes,cpus=A,B,C,D

will _not_ work yet, as , is the option separator for the command-line
option parser, and it will require changing the -numa option parsing
code to handle cpus as a special case.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 vl.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/vl.c b/vl.c
index 955d2ff..cd247be 100644
--- a/vl.c
+++ b/vl.c
@@ -1244,7 +1244,7 @@ char *get_boot_devices_list(size_t *size)
 return list;
 }
 
-static void numa_node_parse_cpus(int nodenr, const char *cpus)
+static void numa_node_parse_cpu_range(int nodenr, const char *cpus)
 {
 char *endptr;
 unsigned long long value, endvalue;
@@ -1288,6 +1288,18 @@ error:
 exit(1);
 }
 
+static void numa_node_parse_cpus(int nodenr, const char *option)
+{
+char **parts;
+int i;
+
+parts = g_strsplit(option, ,, 0);
+for (i = 0; parts[i]; i++) {
+numa_node_parse_cpu_range(nodenr, parts[i]);
+}
+g_strfreev(parts);
+}
+
 static void numa_add(const char *optarg)
 {
 char option[128];
-- 
1.8.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

This allows : to be used a separator between each CPU range, so the
command-line may look like:

  -numa node,cpus=A-B:C-D

Note that the following format, currently used by libvirt:

  -numa nodes,cpus=A-B,C-D

will _not_ work, as , is the option separator for the command-line
option parser, and it would require changing the -numa option parsing
code to handle cpus as a special case.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
Changes v2:
 - Use : as separator
 - Document the new format
---
 qemu-options.hx | 10 --
 vl.c| 14 +-
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 4bc9c85..b135044 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -95,12 +95,18 @@ specifies the maximum number of hotpluggable CPUs.
 ETEXI
 
 DEF(numa, HAS_ARG, QEMU_OPTION_numa,
--numa node[,mem=size][,cpus=cpu[-cpu]][,nodeid=node]\n, QEMU_ARCH_ALL)
+-numa node[,mem=size][,cpus=cpu[-cpu][:...]][,nodeid=node]\n, 
QEMU_ARCH_ALL)
 STEXI
 @item -numa @var{opts}
 @findex -numa
 Simulate a multi node NUMA system. If mem and cpus are omitted, resources
-are split equally.
+are split equally. Multiple CPU ranges in the cpus option may be separated
+by colons. e.g.:
+
+@example
+-numa node,mem=1024,cpus=0-1:4-5:8-9
+-numa node,mem=1024,cpus=2-3:6-7:10-11
+@end example
 ETEXI
 
 DEF(add-fd, HAS_ARG, QEMU_OPTION_add_fd,
diff --git a/vl.c b/vl.c
index 955d2ff..fe632db 100644
--- a/vl.c
+++ b/vl.c
@@ -1244,7 +1244,7 @@ char *get_boot_devices_list(size_t *size)
 return list;
 }
 
-static void numa_node_parse_cpus(int nodenr, const char *cpus)
+static void numa_node_parse_cpu_range(int nodenr, const char *cpus)
 {
 char *endptr;
 unsigned long long value, endvalue;
@@ -1288,6 +1288,18 @@ error:
 exit(1);
 }
 
+static void numa_node_parse_cpus(int nodenr, const char *option)
+{
+char **parts;
+int i;
+
+parts = g_strsplit(option, :, 0);
+for (i = 0; parts[i]; i++) {
+numa_node_parse_cpu_range(nodenr, parts[i]);
+}
+g_strfreev(parts);
+}
+
 static void numa_add(const char *optarg)
 {
 char option[128];
-- 
1.8.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Fri, Feb 22, 2013 at 11:04:24AM +0100, Markus Armbruster wrote:
 Markus Armbruster arm...@redhat.com writes:
 
  Anthony Liguori anth...@codemonkey.ws writes:
 
  Markus Armbruster arm...@redhat.com writes:
 
  Eduardo Habkost ehabk...@redhat.com writes:
 
  This allows , to be used a separator between each CPU range.  Note
  that commas inside key=value command-line options have to be escaped
  using ,,, so the command-line will look like:
 
-numa node,cpus=A,,B,,C,,D
 
  This is really, really ugly, and an embarrassment to document.  Which
  you didn't ;)
 
  What about
 
  -numa node,cpus=A,cpus=B,cpus=C,cpus=D
 
  Yes, QemuOpts lets you do that.  Getting all the values isn't as easy as
  it could be (unless you use Laszlo's opt-visitor), but that could be
  improved.
 
  No more of this.
 
   -numa node,cpus=A:B:C:D 
 
  if you want to express a list.
 
  Okay for command line and human monitor, just don't let it bleed into
  QMP.
 
 Footnotes:
 
 1. Using colons for lists works only as long as the list elements don't
 contain colons.  Fine for numbers.  No good for filenames, network
 addresses, ...
 
 2. QemuOpts helped us reduce the number of ad hoc option parsers,
 improving consistency and error messages quite a bit.  Having every user
 of colon lists roll their own ad hoc parser slides back into the hole
 that motivated QemuOpts.  Let's try to avoid that, please.
 
 3. The existing QemuOpts syntax for list-valued options (repeating the
 option) doesn't have either of these problems.

The problem here seems to be that we want to reuse option parsing code,
but the only reusable syntax we have for command-line options today is
awful (at least for representing lists).

So our only options seem to be: 1) accept some ugliness and things like
A,,B,,C or cpus=A,cpus=B,cpus=C; 2) write ad hoc option parsers; 3)
define/choose a new reusable syntax.

We already have at least 2 better ways to represent config data (config
files and QMP+JSON), but why do we insist in using command-line options
with an awful syntax for everything?

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Mon, Feb 25, 2013 at 10:04:07PM +0100, Andreas Färber wrote:
 Am 21.02.2013 21:57, schrieb Eduardo Habkost:
  On Thu, Feb 21, 2013 at 09:23:22PM +0100, Markus Armbruster wrote:
  Eduardo Habkost ehabk...@redhat.com writes:
 
  This allows , to be used a separator between each CPU range.  Note
  that commas inside key=value command-line options have to be escaped
  using ,,, so the command-line will look like:
 
-numa node,cpus=A,,B,,C,,D
 
  This is really, really ugly, and an embarrassment to document.  Which
  you didn't ;)
  
  I was trying to have an intermediate solution using the current -numa
  parser. I have patches in my queue that will change the code to properly
  use QemuOpts later.
 
 Speaking of which, have you considered using QemuOpts for -cpu? Its
 custom parsing code will probably not handle , escaping at all. ;)

It may be possible, but I'm not sure QemuOpts can handle the +foo,-foo
options (and I am sure we don't want to extend QemuOpts to support
them).

In either case, it's better to do that after we simplify
x86_cpu_parse_featurestr() (with the current patches from Igor), to make
the conversion easier to review later.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Tue, Feb 26, 2013 at 10:53:07AM +0100, Markus Armbruster wrote:
 Eduardo Habkost ehabk...@redhat.com writes:
 
  On Thu, Feb 21, 2013 at 09:23:22PM +0100, Markus Armbruster wrote:
  Eduardo Habkost ehabk...@redhat.com writes:
  
   This allows , to be used a separator between each CPU range.  Note
   that commas inside key=value command-line options have to be escaped
   using ,,, so the command-line will look like:
  
 -numa node,cpus=A,,B,,C,,D
  
  This is really, really ugly, and an embarrassment to document.  Which
  you didn't ;)
 
  I was trying to have an intermediate solution using the current -numa
  parser. I have patches in my queue that will change the code to properly
  use QemuOpts later.
 
  It would be interesting to support the A,B,C,D format in config files,
  though, as it is simple and straighforward when no escaping is required.
 
 Our config file syntax is in a Windows INI dialect: key=value lines
 grouped into sections.  Our dialect requires values to be enclosed in
 quotes.  Commonly, the quotes are optional.  Could be fixed.  It
 supports multi-valued keys the common INI way: multiple key=value lines
 for the same key, one per value
 
 key = A,B,C works when the A, B, C can't contain commas.  Fine for a
 list of numbers.  For long lists, we'd probably want to add a line
 continuation feature.
 
 Strings can contain commas, so you'd have to do something like key =
 A, B, C.  Whether that's still Windows INI is debatable.  More so
 since there's already a common way to do it: one line per value.

I was only thinking about the -numa option problem. Having a more
generic solution would surely be even better.


 
 If we decide INI doesn't meet our needs or desires for pretty syntax, we
 should not extend it beyond its limits into QEMU's very own
 configuration syntax.  We should switch to a common syntax that serves
 our needs and desires.  For what it's worth, we already parse JSON.

I completely agree. But by now I just want to know what we should do
while we don't have a generic parser/syntax that can handle lists in a
pretty way. So:

 
 For me, the INI way to do multi-valued keys is still fine.

Having multiple-valued keys (cpus=A,cpus=B,cpus=C) seems like the best
intermediate solution while we don't have a decent generic syntax.
Except that Anthony doesn't like it.

Anthony, care to explain why exactly you don't want it?


 
  What about
  
  -numa node,cpus=A,cpus=B,cpus=C,cpus=D
 
  Looks better for the command-line usage, at least. I will give it a try.
 
  
  Yes, QemuOpts lets you do that. Getting all the values isn't as easy as
  it could be (unless you use Laszlo's opt-visitor), but that could be
  improved.
 
  Guess what: -numa doesn't even use QemuOpts, and I am not sure the
  current format of -numa will allow QemuOpts to be used easily. I expect
  the proper solution using QemuOpts to involve having a
  standards-compliant numa-node config section instead of this weird
  -numa type,... format where the only valid type that ever existed
  was node.
 
 This is the current -numa syntax, as far as I can tell:
 
 -numa node,KEY=VALUE,...
 
 Recognized KEY=VALUE:
 
 nodeid=UINT
 mem=SIZE
 cpus=[|UINT|UINT-UINT]
 
 Unrecognized KEYs are silently ignored.
 
 This should fit into QemuOpts just fine.  Sketch:
 
 static QemuOptsList qemu_numa_opts = {
 .name = numa,
 .implied_opt_name = type
 .head = QTAILQ_HEAD_INITIALIZER(qemu_rtc_numa.head),
 .desc = {
 {
 .name = type,
 .type = QEMU_OPT_STRING,
 .help = node type
 },

The node part is not a node type, it is an numa option type, and
the only valid option type today is node (which is what makes the
current syntax seem weird to me).

I would simply drop the numa part from the command-line argument and
name the new config section numa-node. I will send patches to do that,
later.


 {
 .name = nodeid,
 .type = QEMU_OPT_NUMBER,
 .help = node ID
 }, {
 .name = mem,
 .type = QEMU_OPT_SIZE,
 .help = memory size
 }, {

I need to double-check that QEMU_OPT_SIZE has exactly the same behavior
of the ad-hoc parser, first.

 .name = cpus,
 .type = QEMU_OPT_STRING,
 .help = CPU range
 },
 { /* end of list */ }
 },
 };
 
 
 type = qemu_opt_get(opts);
 if (!type || strcmp(type, node)) {
 // error
 }
 // get and record nodeid, mem
 // get, parse and record cpus
 
 This rejects unrecognized keys, unlike the current code.  Declare bug
 fix ;)

Good.  :-)

 
 To support discontinuous CPU sets, simply get all values of key cpus.

I think I have an unfinished work branch that did that. But Paolo also
have a similar patch on his tree that does the conversion to QemuOpts in
a much simpler way.

In either case, first I need to check if QemuOpts will match the ad-hoc
parser behavior

Re: [libvirt] [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Tue, Feb 26, 2013 at 11:50:08AM +0100, Markus Armbruster wrote:
 Eduardo Habkost ehabk...@redhat.com writes:
 
  This allows : to be used a separator between each CPU range, so the
  command-line may look like:
 
-numa node,cpus=A-B:C-D
 
  Note that the following format, currently used by libvirt:
 
-numa nodes,cpus=A-B,C-D
 
  will _not_ work, as , is the option separator for the command-line
  option parser, and it would require changing the -numa option parsing
  code to handle cpus as a special case.
 
  Signed-off-by: Eduardo Habkost ehabk...@redhat.com
  ---
  Changes v2:
   - Use : as separator
   - Document the new format
 
 See also discussion on multi-valued keys in command line option
 arguments and config files in v1 thread.  Hopefully we can reach a
 conclusion soon, and then we'll see whether this patch is what we want.

Yeah, let's drop this patch by now. I am starting to be convinced that
cpus=A,cpus=B,cpus=C is the best approach. It is not pretty, but at
least it uses generic parser code instead of yet another ad-hoc parser.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Tue, Feb 26, 2013 at 01:35:14PM -0600, Anthony Liguori wrote:
 Eduardo Habkost ehabk...@redhat.com writes:
 
  On Tue, Feb 26, 2013 at 11:50:08AM +0100, Markus Armbruster wrote:
  Eduardo Habkost ehabk...@redhat.com writes:
  
   This allows : to be used a separator between each CPU range, so the
   command-line may look like:
  
 -numa node,cpus=A-B:C-D
  
   Note that the following format, currently used by libvirt:
  
 -numa nodes,cpus=A-B,C-D
  
   will _not_ work, as , is the option separator for the command-line
   option parser, and it would require changing the -numa option parsing
   code to handle cpus as a special case.
  
   Signed-off-by: Eduardo Habkost ehabk...@redhat.com
   ---
   Changes v2:
- Use : as separator
- Document the new format
  
  See also discussion on multi-valued keys in command line option
  arguments and config files in v1 thread.  Hopefully we can reach a
  conclusion soon, and then we'll see whether this patch is what we want.
 
  Yeah, let's drop this patch by now. I am starting to be convinced that
  cpus=A,cpus=B,cpus=C is the best approach. It is not pretty, but at
  least it uses generic parser code instead of yet another ad-hoc
  parser.
 
 No, we cannot rely on this behavior.  We had to do it to support
 backwards compat with netdev but it should not be used anywhere else.

Why? What should be the proper and generic way to represent and parse
lists, then?

There are many arguments being exposed at the v1 thread. See
 Message-ID: 512cc6d6.4060...@redhat.com.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Wed, Feb 27, 2013 at 09:42:50AM -0600, Anthony Liguori wrote:
 Paolo Bonzini pbonz...@redhat.com writes:
 
  Il 26/02/2013 20:35, Anthony Liguori ha scritto:
   
   See also discussion on multi-valued keys in command line option
   arguments and config files in v1 thread.  Hopefully we can reach a
   conclusion soon, and then we'll see whether this patch is what we 
   want.
  
   Yeah, let's drop this patch by now. I am starting to be convinced that
   cpus=A,cpus=B,cpus=C is the best approach. It is not pretty, but at
   least it uses generic parser code instead of yet another ad-hoc
   parser.
  No, we cannot rely on this behavior.  We had to do it to support
  backwards compat with netdev but it should not be used anywhere else.
 
  We chose a config format (git's) because it was a good match for
  QemuOpts, and multiple-valued operations are well supported by that
  config format; see git-config(1).  There is no reason to consider it a
  backwards-compatibility hack.

 There's such thing as list support in QemuOpts.
[skipping stuff about internal implementation details that don't matter]
 
 If we want to have list syntax, we need to introduce first class support
 for it.

Absolutely. But how the syntax for it should look like?


 Here's a simple example of how to do this.  Obviously we would
 want to introduce some better error checking so we can catch if someone
 tries to access a list with a non-list accessor.  We also would need
 list accessor functions.
 
 But it's really not hard at all.

Of course. Once we decide how the syntax will look like, implementing
it should be very easy. But as far as I can see, we were trying to
discuss what's the appropriate syntax, here.

I still don't see why option=A:B:C with no possibility of having list
items containing : (like your proposal below) is a better generic
syntax for lists than option=A,option=B,option=C.


 From 4ee7ed36d597f0defd78baac7480ecb29e11e1c1 Mon Sep 17 00:00:00 2001
 From: Anthony Liguori aligu...@us.ibm.com
 Date: Wed, 27 Feb 2013 09:32:09 -0600
 Subject: [PATCH] qemu-opts: support lists
 
 Signed-off-by: Anthony Liguori aligu...@us.ibm.com
 ---
  include/qemu/option.h |  2 ++
  util/qemu-option.c| 12 
  2 files changed, 14 insertions(+)
 
 diff --git a/include/qemu/option.h b/include/qemu/option.h
 index ba197cd..e4808c3 100644
 --- a/include/qemu/option.h
 +++ b/include/qemu/option.h
 @@ -41,6 +41,7 @@ enum QEMUOptionParType {
  typedef struct QEMUOptionParameter {
  const char *name;
  enum QEMUOptionParType type;
 +bool list;
  union {
  uint64_t n;
  char* s;
 @@ -95,6 +96,7 @@ enum QemuOptType {
  typedef struct QemuOptDesc {
  const char *name;
  enum QemuOptType type;
 +bool list;
  const char *help;
  } QemuOptDesc;
  
 diff --git a/util/qemu-option.c b/util/qemu-option.c
 index 5a1d03c..6b1ae6e 100644
 --- a/util/qemu-option.c
 +++ b/util/qemu-option.c
 @@ -636,6 +636,18 @@ static void opt_set(QemuOpts *opts, const char *name, 
 const char *value,
  return;
  }
  
 +if (desc-list  strchr(value, ':')) {
 +gchar **tokens = g_strsplit(value, :, 0);
 +int i;
 +for (i = 0; tokens[i]; i++) {
 +opt_set(opts, name, tokens[i], prepend, errp);
 +if (error_is_set(errp)) {
 +return;
 +}
 +}
 +g_strfreev(tokens);
 +}
 +
  opt = g_malloc0(sizeof(*opt));
  opt-name = g_strdup(name);
  opt-opts = opts;
 -- 
 1.8.0
 

 
 Regards,
 
 Anthony Liguori
 
 
  Paolo


-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Wed, Feb 27, 2013 at 04:57:15PM +0100, Paolo Bonzini wrote:
 Il 27/02/2013 16:42, Anthony Liguori ha scritto:
  There's such thing as list support in QemuOpts.  The only way
  QemuOptsVisitor was able to implement it was to expose QemuOpts publicly
  via options_int.h and rely on a implementation detail.
  
  There are fixed types supported by QemuOpts.  It just so happens that
  whenever qemu_opt_set() is called, instead of replacing the last
  instance, the value is either prepended or appended in order to
  implement a replace or set-if-unset behavior.
 
 Fair enough.  Nobody said the implementation is pretty.
 
  If we want to have list syntax, we need to introduce first class support
  for it.  Here's a simple example of how to do this.
 
 If it is meant as a prototype only, and the final command-line syntax
 would be with repeated keys, that's okay.  I think that Eduardo/Markus/I
 are focusing on the user interface, you're focusing in the implementation.
 
 In the meanwhile, however, it seems to me that Eduardo can use
 QemuOptsVisitor---which can also hide the details and provide type safety.

Whatever I use to implement it, I still need to know how the
command-line syntax will look like, because we need to tell libvirt
developers how they should write the QEMU command-line.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Wed, Feb 27, 2013 at 05:58:39PM +0100, Paolo Bonzini wrote:
 Il 27/02/2013 17:19, Eduardo Habkost ha scritto:
   
   If it is meant as a prototype only, and the final command-line syntax
   would be with repeated keys, that's okay.  I think that Eduardo/Markus/I
   are focusing on the user interface, you're focusing in the 
   implementation.
   
   In the meanwhile, however, it seems to me that Eduardo can use
   QemuOptsVisitor---which can also hide the details and provide type 
   safety.
  Whatever I use to implement it, I still need to know how the
  command-line syntax will look like, because we need to tell libvirt
  developers how they should write the QEMU command-line.
 
 I don't think any syntax makes sense except cpus=A,cpus=B.  How we
 implement it is another story.

I agree completely, and I still don't know why Anthony doesn't like it.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option

[Eduardo Habkost]

On Wed, Feb 27, 2013 at 11:04:08AM -0600, Anthony Liguori wrote:
 Eduardo Habkost ehabk...@redhat.com writes:
 
  On Wed, Feb 27, 2013 at 04:57:15PM +0100, Paolo Bonzini wrote:
  Il 27/02/2013 16:42, Anthony Liguori ha scritto:
   There's such thing as list support in QemuOpts.  The only way
   QemuOptsVisitor was able to implement it was to expose QemuOpts publicly
   via options_int.h and rely on a implementation detail.
   
   There are fixed types supported by QemuOpts.  It just so happens that
   whenever qemu_opt_set() is called, instead of replacing the last
   instance, the value is either prepended or appended in order to
   implement a replace or set-if-unset behavior.
  
  Fair enough.  Nobody said the implementation is pretty.
  
   If we want to have list syntax, we need to introduce first class support
   for it.  Here's a simple example of how to do this.
  
  If it is meant as a prototype only, and the final command-line syntax
  would be with repeated keys, that's okay.  I think that Eduardo/Markus/I
  are focusing on the user interface, you're focusing in the implementation.
  
  In the meanwhile, however, it seems to me that Eduardo can use
  QemuOptsVisitor---which can also hide the details and provide type safety.
 
  Whatever I use to implement it, I still need to know how the
  command-line syntax will look like, because we need to tell libvirt
  developers how they should write the QEMU command-line.
 
 Command line syntax is not committed until it appears in a release.
 libvirt *should not* assume any specific syntax until the 1.5 release
 ships.

I am just talking about communication with libvirt developers.
Developers surely write code and test their work in progress using
unreleased QEMU code, instead of waiting for an official release. Nobody
suggested releasing a libvirt version that relies on an unreleased QEMU
feature.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Fri, Mar 01, 2013 at 02:12:38PM +0100, Jiri Denemark wrote:
 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 enumerate the libvirt requirements and current problems, and
  how we should be able to solve those problems using the X86CPU
  subclasses and properties, on the following wiki page:
  
  http://wiki.qemu.org/Features/CPUModels#Interfaces.2Frequirements_from_libvirt
 
  = Ensuring predictable set of guest features =
  
  Requirement: libvirt needs to ensure all features required on the 
  command-line
  are present and exposed to the guest.
  
  Current problem: libvirt doesn't use the enforce flag so it can't 
  guarantee
  that a given feature will be actually exposed to the guest.
  
  Solution: use the enforce flag on the -cpu option.
 
 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 with QEMU, some configurations in fact rely on QEMU
 dropping features it can't provide. Of course, that's bad for several
 reasons but we don't want such configurations to suddenly stop working.
 We want to first fix the CPU specs libvirt creates so that we know they
 will work with enforce.

Also: more important than fixing the CPU definitions from libvirt, is to
ask QEMU for host capabilities and CPU model definitions. The whole
point of this is to solve the CPU model data duplication/synchronization
problems between libvirt and QEMU.

Once you are able to query CPU model definitions on runtime, you don't
even need to make cpu_map.xml agree with QEMU. You can simply ask QEMU
how each model looks like, and remove/add features from the command-line
as necessary, so the resulting VM matches what the user asked for.


 
  Limitation: no proper machine-friendly interface to report which 
  features
  are missing.
  
  Workaround: See querying for host capabilities below.
 
 I doubt we will be ready to start using enforce before the machine
 friendly interface is available...

If you query for the -cpu host capabilities first and ensure all
features from a CPU model is available, enforce is supposed to not fail.

I understand that a machine-friendly error reporting for enforce would
be very useful, but note that if enforce fails, it is probably already
too late for libvirt, and that means that what libvirt thinks about host
capabilities and CPU models is already incorrect.


The main problem preventing us from making a machine-friendly interface
is that enforce makes QEMU abort immediately, making us lose the main
machine-friendly communication mechanism, that is QMP.

(But I had an idea to solve that, look for removed-features below for
a description).


 
 
  = Listing CPU models =
  
  Requirement: libvirt needs to know which CPU models are available to be used
  with the -cpu option.
  
  Current problem: libvirt relies on help output parsing for that.
  
  Solution: use QMP qom-list-types command.
  
  Dependency: X86CPU subclasses.
  Limitation: needs a live QEMU process for the query.
 
 No problem, we already run QEMU and use several QMP commands to probe
 its capabilities. And qom-list-types is actually one of them. To get
 the list of CPU models, we would just call
 
 {
 execute: qom-list-types,
 arguments: {
 implements: X86CPU
 }
 }
 
 right? What about other non-x86 architectures? Will we need to use
 different class name or is there a generic CPU class that could be used
 universally?

Actually I don't know much about the QMP command syntax and didn't test
it a lot. But that's basically how I think it will look like. Except
that instead of X86CPU, the type name is x86_64-cpu (on
qemu-system-x86_64) and i386-cpu (on qemu-system-i386). Maybe it is
easier to simply use: implements: cpu, abstract: false }.

We may also end up with different CPU model classes for KVM and TCG,
this is still under discussion.

Another caveat: the CPU model class names will be longer than the names
used on the -cpu command-line: something like model-arch-cpu or
model-kvm-arch-cpu.


 
  Solution: use QMP query-cpu-definitions command.
  
  Limitation: needs a live QEMU process for the query.
 
 IIUC, the result of this command will depend on machine type and we
 can't use -M none we currently use for probing, right?

The class data don't depend on machine-types. But the resulting CPU
objects may look different depending on machine type.

In other words: you don't need -M to list CPU models, but you need -M if
you want to know which features are going to be available on each model,
exactly.

 
  == Future plans ==
  
  It would be interesting to get rid of the requirement for a live QEMU

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

[Eduardo Habkost]

On Fri, Mar 01, 2013 at 02:28:37PM +0100, Jiri Denemark wrote:
 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 depend on:
  
• Host CPU (hardware) capabilities;
• Kernel capabilities (reported by GET_SUPPORTED_CPUID);
• QEMU capabilities;
• Specific configuration options (e.g. in-kernel IRQ chip is required for
  some features).
 
 Actually, one more thing. Can any of these requirements change while a
 host is up and QEMU is not upgraded? I believe, host CPU capabilities
 can only change when the host starts. Kernel capabilities are a bit less
 clear since I guess they could possibly change when kvm module is
 unloaded and loaded back with a different options. QEMU capabilities
 should only change when different version is installed. And the specific
 configuration options are the most unclear to me. The reason I'm asking
 is whether libvirt could run-time cache CPU definitions (including all
 model details) in the same way we currently cache QEMU capabilities,
 such as availability of specific QMP commands.


That's a good question. Let's check each item so I don't forget any
detail:

• Host CPU (hardware) capabilities;

This shouldn't change without a host reboot.

• Kernel capabilities (reported by GET_SUPPORTED_CPUID);

This may possibly change if the KVM module is unloaded and reloaded with
different options, but... I guess we should simply require libvirtd to
be restarted if any user does that?

• QEMU capabilities;

This shouldn't change as long as the QEMU binary doesn't change.


• Specific configuration options (e.g. in-kernel IRQ chip is required for
  some features).

This part seems tricky. Currently kernel-irqchip is probably the only
option that affects which features are available, but what if other QEMU
options affect the set of features too?

I believe the answer is to rely on machine-types. I mean: if a new
option that affects -cpu host and the set of available CPU features is
created, there are two options:

  1) Using the default value;
  2) Setting the option explicitly.

1) If using the default value, the default will depend on machine-type, so
libvirt should already consider machine-type as an option that affects
available-CPU-features.

2) If using an explicit value, libvirt should use the explicit value only
after being changed to take into account the fact that the option
affects available-CPU-features.

So, let's add one more item to the list. The set of available
capabilities depend on:

  • Host CPU (hardware) capabilities;
  • Kernel capabilities (reported by GET_SUPPORTED_CPUID);
  • QEMU capabilities;
  • Specific configuration options:
• kernel-irqchip (currently affects tsc-deadline and x2apic, but may
  affect other features in the future)
• machine-type (may affect any feature in the future)

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Fri, Mar 01, 2013 at 07:31:46PM +0100, Andreas Färber wrote:
 Am 01.03.2013 14:12, schrieb Jiri Denemark:
  On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote:
  = Listing CPU models =
 
  Requirement: libvirt needs to know which CPU models are available to be 
  used
  with the -cpu option.
 
  Current problem: libvirt relies on help output parsing for that.
 
 query-cpu-definitions is the QMP command to retrieve values compatible
 with -cpu.
 
 And if libvirt is not using it, I really don't understand why the work
 of maintaining this crappy interface has been pushed onto us in the
 first place? There is no reuse between -cpu ? and QMP implementations so
 it's just extra work, there is no communicated or implemented way to
 extend the arch_query_cpu_definitions() implementation to become more
 usable for command line output implementation (e.g., associating a PVR
 value with the model name for ppc) and, while we're at it, it uses
 global functions plus a stub rather than a CPUState hook with a no-op
 default implementation in qom/cpu.c...

I have the same questions you have.  :-)

But my main complaint about query-cpu-definitions is not about the
implementation: it's that the interface was introduced without taking
into account the requirements of libvirt regarding CPU features. It was
found to be not appropriate for what libvirt needs[1], but somehow it
got applied anyway.

[1] http://article.gmane.org/gmane.comp.emulators.qemu/164772

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Fri, Mar 01, 2013 at 06:34:31PM +, Daniel P. Berrange wrote:
 On Fri, Mar 01, 2013 at 07:31:46PM +0100, Andreas Färber wrote:
  Am 01.03.2013 14:12, schrieb Jiri Denemark:
   On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote:
   = Listing CPU models =
  
   Requirement: libvirt needs to know which CPU models are available to be 
   used
   with the -cpu option.
  
   Current problem: libvirt relies on help output parsing for that.
  
  query-cpu-definitions is the QMP command to retrieve values compatible
  with -cpu.
 
 Yep, Jiri is wrong here actually. -cpu parsing is what we used to
 do. With latest libvirt + QEMU we do use query-cpu-definitions
 and have no help parsing code used at all.

I wrote the above, not Jiri. I will fix the wiki page to note that.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Fri, Mar 01, 2013 at 11:56:00PM +0100, Jiri Denemark wrote:
[...]
= Getting information about CPU models =

Requirement: libvirt uses the predefined CPU models from QEMU, but it 
needs to
be able to query for CPU model details, to find out how it can create a 
VM that
matches what was requested by the user.

Current problem: libvirt has a copy of the CPU model definitions on its
cpu_map.xml file, and the copy can be out of sync in case CPU models in 
QEMU
change. libvirt also assumes that the set of features on each model is 
always
the same on all machine-types, which is not true.

Challenge: the resulting CPU features depend on lots of factors, 
including
the machine-type.

Workaround: start a paused VM and query for the CPU device 
information
after the CPU was created.
  
  I just noticed another problem here, but this gave me an idea that would
  help solve the enforce error reporting problem:
  
Problem: qemu -machine M -cpu model will create CPU objects
where the CPU features are _already_ filtered based on host
capabilities.
 
 Ah, it seems logical now that you mention it :-)
 
  * Using enforce wouldn't solve it, because then QEMU would abort, and
QMP would be unavailable.
  
  Solution: we could have a CPU object property like
  removed-features that would have the list of features that were
  disabled because they are not supported by the host (and would make
  enforce fail).
  
* This would solve the problem above and also be a machine-friendly
  way to check for possible enforce errors.
  
* In other words: instead of enforce, libvirt could use check
  instead of enforce, and before unpausing the VM (or even starting
  migration), it should first check if the removed-features 
  property is
  empty.
  
  Would that work for you?
 
 Yes, that seems like it could work. In fact, it seems much better than
 using enforce and trying to deal with aborted QEMU.

To make the libvirt logic simpler, we could do this: have a force mode
(in addition to check/enforce), that wouldn't filter any CPU feature
based on host capabilities. This way libvirt wouldn't need any
non-trivial logic to combine the f-* flags and removed-features to
find out the CPU model details.

Then libvirt would need to look only at f-* to find out the CPU model
details at probing time (as long as force is used at probing time),
and just make sure removed-features is empty before starting the VM
(optionally parsing its value or checking the f-* property values, to
find out which features are missing exactly).

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 0/4] target-i386: Add feature-words CPU object property

[Eduardo Habkost]

As the work to get X86CPU subclasses static properties defined is taking very
long to get reviewed and we risk not getting it finished in 1.5, I am sending
an alternative mechanism to allow libvirt to probe for CPU model information.

It's interesting to note that this alternative solution is actually _easier_ to
use for libvirt, because libvirt logic is already based on CPUID bit values, not
feature names, so it should be very easy to convert the current libvirt code
that (incorrectly) query the host CPU directly for available features to instead
start QEMU with -cpu host and use the feature-words array information to
find out which CPU features are supported by the host.

The property will have two main use cases:
 - Checking host capabilities, by checking the features of the host
   CPU model;
 - Checking which features are enabled on each CPU model.

This series has two alternative implementations, so both approaches can get
feedback: patch 3 has a non-qapi implementation, that simply builds the list and
sets the struct fields manually. Patch 4 converts that implementation to a qapi-
based implementation.

(BTW, I really missed some documentation on the list-related visitor functions,
when writing this code)

Example output:

  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=feature-words
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 1
  item[0].features: 126614521
  item[1].cpuid-register: ECX
  item[1].cpuid-input-eax: 1
  item[1].features: 2155880449
  item[2].cpuid-register: EBX
  item[2].cpuid-input-eax: 7
  item[2].features: 0
  item[2].cpuid-input-ecx: 0
  item[3].cpuid-register: EDX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 563346425
  item[4].cpuid-register: ECX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 101
  item[5].cpuid-register: EDX
  item[5].cpuid-input-eax: 3221225473
  item[5].features: 0
  item[6].cpuid-register: EAX
  item[6].cpuid-input-eax: 1073741825
  item[6].features: 0
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 2147483658
  item[7].features: 0

I plan to send another RFC as followup soon, that will add:

 * -cpu force (or nofilter, or something else; I haven't decided about the
   name, yet) flag, to disable feature filtering based on host capabilities.
 * filtered-features property, listing which features were filtered out
   because of missing host capabilities (to allow libvirt to implement enforce
   mode in a more reliable way).

Eduardo Habkost (4):
  target-i386: Add ECX information to FeatureWordInfo
  target-i386: Move feature word array outside get_register_name_32()
  target-i386: Add feature-words property
  target-i386: Use qapi for x86_cpu_get_feature_words()

 .gitignore   |  2 +
 Makefile | 11 +
 Makefile.objs|  5 +++
 cpu-qapi-schema.json | 31 ++
 target-i386/Makefile.objs|  1 +
 target-i386/cpu-qapi-schema.json | 31 ++
 target-i386/cpu.c| 92 +---
 7 files changed, 158 insertions(+), 15 deletions(-)
 create mode 100644 cpu-qapi-schema.json
 create mode 100644 target-i386/cpu-qapi-schema.json

-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 1/4] target-i386: Add ECX information to FeatureWordInfo

[Eduardo Habkost]

FEAT_7_0_EBX uses ECX as input, so we have to take that into account
when reporting feature word values.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 4b43759..974a8c6 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -151,8 +151,10 @@ static const char *cpuid_7_0_ebx_feature_name[] = {
 
 typedef struct FeatureWordInfo {
 const char **feat_names;
-uint32_t cpuid_eax; /* Input EAX for CPUID */
-int cpuid_reg;  /* R_* register constant */
+uint32_t cpuid_eax;   /* Input EAX for CPUID */
+bool cpuid_needs_ecx; /* CPUID instruction uses ECX as input */
+uint32_t cpuid_ecx;   /* Input ECX value for CPUID */
+int cpuid_reg;/* output register (R_* constant) */
 } FeatureWordInfo;
 
 static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
@@ -186,7 +188,9 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 },
 [FEAT_7_0_EBX] = {
 .feat_names = cpuid_7_0_ebx_feature_name,
-.cpuid_eax = 7, .cpuid_reg = R_EBX,
+.cpuid_eax = 7,
+.cpuid_needs_ecx = true, .cpuid_ecx = 0,
+.cpuid_reg = R_EBX,
 },
 };
 
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 3/4] target-i386: Add feature-words property

[Eduardo Habkost]

This property will be useful for libvirt, as libvirt already has logic
based on low-level feature bits (not feature names), so it will be
really easy to convert the current libvirt logic to something using the
feature-words property.

The property will have two main use cases:
 - Checking host capabilities, by checking the features of the host
   CPU model
 - Checking which features are enabled on each CPU model

Example output:

  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=feature-words
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 1
  item[0].features: 126614521
  item[1].cpuid-register: ECX
  item[1].cpuid-input-eax: 1
  item[1].features: 2155880449
  item[2].cpuid-register: EBX
  item[2].cpuid-input-eax: 7
  item[2].features: 0
  item[2].cpuid-input-ecx: 0
  item[3].cpuid-register: EDX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 563346425
  item[4].cpuid-register: ECX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 101
  item[5].cpuid-register: EDX
  item[5].cpuid-input-eax: 3221225473
  item[5].features: 0
  item[6].cpuid-register: EAX
  item[6].cpuid-input-eax: 1073741825
  item[6].features: 0
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 2147483658
  item[7].features: 0

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
* This is the solution not using qapi. The next patch will introduce a
  solution using qapi, so both approaches can get feedback.
* Current solution is not based on the feature word array patch,
  but it may be easily rebased and simplified if we decide to include
  the CPUX86State feature_word array later.
---
 target-i386/cpu.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 2020147..ebf6358 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1277,6 +1277,44 @@ static void x86_cpuid_set_tsc_freq(Object *obj, Visitor 
*v, void *opaque,
 cpu-env.tsc_khz = value / 1000;
 }
 
+static void x86_cpu_get_feature_words(Object *obj, Visitor *v, void *opaque,
+   const char *name, Error **errp)
+{
+X86CPU *cpu = X86_CPU(obj);
+CPUX86State *env = cpu-env;
+FeatureWord w;
+Error *err = NULL;
+uint32_t feat_values[FEATURE_WORDS] = { };
+
+/* We need to set the entries one-by-one, by now, while we don't have
+ * a single feature_words array on X86CPU
+ */
+feat_values[FEAT_1_EDX] = env-cpuid_features;
+feat_values[FEAT_1_ECX] = env-cpuid_ext_features;
+feat_values[FEAT_8000_0001_EDX] = env-cpuid_ext2_features;
+feat_values[FEAT_8000_0001_ECX] = env-cpuid_ext3_features;
+feat_values[FEAT_C000_0001_EDX] = env-cpuid_ext4_features;
+feat_values[FEAT_KVM] = env-cpuid_kvm_features;
+feat_values[FEAT_SVM] = env-cpuid_svm_features;
+feat_values[FEAT_7_0_EBX] = env-cpuid_7_0_ebx_features;
+
+visit_start_list(v, feature-words, err);
+for (w = 0; w  FEATURE_WORDS; w++) {
+FeatureWordInfo *wi = feature_word_info[w];
+visit_start_struct(v, NULL, NULL, NULL, 0, err);
+visit_type_uint32(v, wi-cpuid_eax, cpuid-input-eax, err);
+if (wi-cpuid_needs_ecx) {
+visit_type_uint32(v, wi-cpuid_ecx, cpuid-input-ecx, err);
+}
+visit_type_enum(v, wi-cpuid_reg, reg_names_32, x86-register-32,
+cpuid-register, err);
+visit_type_uint32(v, feat_values[w], features, err);
+visit_end_struct(v, err);
+}
+visit_end_list(v, err);
+error_propagate(errp, err);
+}
+
 static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def, const char *name)
 {
 x86_def_t *def;
@@ -2232,6 +2270,9 @@ static void x86_cpu_initfn(Object *obj)
 object_property_add(obj, tsc-frequency, int,
 x86_cpuid_get_tsc_freq,
 x86_cpuid_set_tsc_freq, NULL, NULL, NULL);
+object_property_add(obj, feature-words, x86-cpu-feature-words,
+x86_cpu_get_feature_words,
+NULL, NULL, NULL, NULL);
 
 env-cpuid_apic_id = x86_cpu_apic_id_from_index(cs-cpu_index);
 
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 2/4] target-i386: Move feature word array outside get_register_name_32()

[Eduardo Habkost]

The array will be used by the feature-words properties to output the
register enum value.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu.c | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 974a8c6..2020147 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -194,23 +194,24 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 },
 };
 
+static const char *reg_names_32[CPU_NB_REGS32] = {
+[R_EAX] = EAX,
+[R_ECX] = ECX,
+[R_EDX] = EDX,
+[R_EBX] = EBX,
+[R_ESP] = ESP,
+[R_EBP] = EBP,
+[R_ESI] = ESI,
+[R_EDI] = EDI,
+};
+
+
 const char *get_register_name_32(unsigned int reg)
 {
-static const char *reg_names[CPU_NB_REGS32] = {
-[R_EAX] = EAX,
-[R_ECX] = ECX,
-[R_EDX] = EDX,
-[R_EBX] = EBX,
-[R_ESP] = ESP,
-[R_EBP] = EBP,
-[R_ESI] = ESI,
-[R_EDI] = EDI,
-};
-
 if (reg  CPU_NB_REGS32) {
 return NULL;
 }
-return reg_names[reg];
+return reg_names_32[reg];
 }
 
 /* collects per-function cpuid data
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [RFC 2/4] target-i386: Move feature word array outside get_register_name_32()

[Eduardo Habkost]

On Mon, Apr 01, 2013 at 04:46:47PM -0300, Eduardo Habkost wrote:
 The array will be used by the feature-words properties to output the
 register enum value.

Oops, the patch subject line is wrong: it was supposed to say Move
register name array.

 
 Signed-off-by: Eduardo Habkost ehabk...@redhat.com
 ---
  target-i386/cpu.c | 25 +
  1 file changed, 13 insertions(+), 12 deletions(-)
 
 diff --git a/target-i386/cpu.c b/target-i386/cpu.c
 index 974a8c6..2020147 100644
 --- a/target-i386/cpu.c
 +++ b/target-i386/cpu.c
 @@ -194,23 +194,24 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] 
 = {
  },
  };
  
 +static const char *reg_names_32[CPU_NB_REGS32] = {
 +[R_EAX] = EAX,
 +[R_ECX] = ECX,
 +[R_EDX] = EDX,
 +[R_EBX] = EBX,
 +[R_ESP] = ESP,
 +[R_EBP] = EBP,
 +[R_ESI] = ESI,
 +[R_EDI] = EDI,
 +};
 +
 +
  const char *get_register_name_32(unsigned int reg)
  {
 -static const char *reg_names[CPU_NB_REGS32] = {
 -[R_EAX] = EAX,
 -[R_ECX] = ECX,
 -[R_EDX] = EDX,
 -[R_EBX] = EBX,
 -[R_ESP] = ESP,
 -[R_EBP] = EBP,
 -[R_ESI] = ESI,
 -[R_EDI] = EDI,
 -};
 -
  if (reg  CPU_NB_REGS32) {
  return NULL;
  }
 -return reg_names[reg];
 +return reg_names_32[reg];
  }
  
  /* collects per-function cpuid data
 -- 
 1.8.1.4
 
 

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 2/5] target-i386: Add feature-words property

[Eduardo Habkost]

This property will be useful for libvirt, as libvirt already has logic
based on low-level feature bits (not feature names), so it will be
really easy to convert the current libvirt logic to something using the
feature-words property.

The property will have two main use cases:
 - Checking host capabilities, by checking the features of the host
   CPU model
 - Checking which features are enabled on each CPU model

Example output:

  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=feature-words
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 101
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 563346425
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 0
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 2155880449
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 126614521

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
Changes v1 - v2:
 * Merge the non-qapi and qapi patches, to keep series simpler
 * Use the feature word array series as base, so we don't have
   to set the feature word values one-by-one in the code
 * Change type name of property from x86-cpu-feature-words to
   X86CPUFeatureWordInfo
 * Remove cpu-qapi-schema.json and simply add the type definitions
   to qapi-schema.json, to keep the changes simpler
   * This required compiling qapi-types.o and qapi-visit.o into
 *-user as well
---
 .gitignore|  2 ++
 Makefile.objs |  7 +-
 qapi-schema.json  | 32 +
 target-i386/cpu.c | 70 +--
 4 files changed, 98 insertions(+), 13 deletions(-)

diff --git a/.gitignore b/.gitignore
index 487813a..71408e3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,6 +21,8 @@ linux-headers/asm
 qapi-generated
 qapi-types.[ch]
 qapi-visit.[ch]
+cpu-qapi-types.[ch]
+cpu-qapi-visit.[ch]
 qmp-commands.h
 qmp-marshal.c
 qemu-doc.html
diff --git a/Makefile.objs b/Makefile.objs
index f99841c..944a0e8 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -87,10 +87,15 @@ common-obj-$(CONFIG_SMARTCARD_NSS) += $(libcacard-y)
 ##
 # qapi
 
-common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o
+common-obj-y += qmp-marshal.o
 common-obj-y += qmp.o hmp.o
 endif
 
+##
+# some qapi visitors are used by both system and user emulation:
+
+common-obj-y += qapi-visit.o qapi-types.o
+
 ###
 # Target-independent parts used in system and user emulation
 common-obj-y += qemu-log.o
diff --git a/qapi-schema.json b/qapi-schema.json
index f629a24..5e6c221 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3453,3 +3453,35 @@
 # Since: 1.5
 ##
 { 'command': 'query-tpm', 'returns': ['TPMInfo'] }
+
+##
+# @X86CPURegister32
+#
+# A X86 32-bit register
+#
+# Since: 1.5
+##
+{ 'enum': 'X86CPURegister32',
+  'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
+
+##
+# @X86CPUFeatureWordInfo
+#
+# Information about a X86 CPU feature word
+#
+# @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word
+#
+# @cpuid-input-ecx: #optional Input ECX value for CPUID instruction for that
+#   feature word
+#
+# @cpuid-register: Output register containing the feature bits
+#
+# @features: value of output register, containing the feature bits
+#
+# Since: 1.5
+##
+{ 'type': 'X86CPUFeatureWordInfo',
+  'data': { 'cpuid-input-eax': 'int',
+'*cpuid-input-ecx': 'int',
+'cpuid-register': 'X86CPURegister32',
+'features': 'int' } }
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 6bb228b..75ffc9e 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -30,6 +30,8 @@
 #include qemu/config-file.h
 #include qapi/qmp/qerror.h
 
+#include qapi-types.h
+#include qapi-visit.h
 #include qapi/visitor.h
 #include sysemu/arch_init.h
 
@@ -194,23 +196,34 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 },
 };
 
+typedef struct X86RegisterInfo32 {
+/* Name of register */
+const char *name;
+/* QAPI enum value register */
+X86CPURegister32 qapi_enum;
+} X86RegisterInfo32;
+
+#define REGISTER(reg) \
+[R_##reg] = { .name = #reg, .qapi_enum = X86_C_P_U_REGISTER32_##reg }
+X86RegisterInfo32 x86_reg_info_32[CPU_NB_REGS32] = {
+REGISTER(EAX),
+REGISTER(ECX),
+REGISTER(EDX),
+REGISTER(EBX),
+REGISTER(ESP),
+REGISTER(EBP),
+REGISTER

[libvirt] [RFC 5/5] target-i386: Add filtered-features property to X86CPU

[Eduardo Habkost]

This property will contain all the features that were removed from the
CPU because they are not supported by the host.

This way, libvirt or other management tools can emulate the
check/enforce behavior by checking if filtered-properties is all zeroes,
before starting the guest.

Example output where some features were missing:

  $ ./install/bin/qemu-system-x86_64 -enable-kvm -cpu Haswell,check -S -qmp 
unix:/tmp/m,server,nowait
  warning: host doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
  warning: host doesn't support requested feature: CPUID.01H:ECX.movbe [bit 22]
  warning: host doesn't support requested feature: CPUID.01H:ECX.tsc-deadline 
[bit 24]
  warning: host doesn't support requested feature: CPUID.01H:ECX.xsave [bit 26]
  warning: host doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
  warning: host doesn't support requested feature: CPUID.07H:EBX.fsgsbase [bit 
0]
  warning: host doesn't support requested feature: CPUID.07H:EBX.bmi1 [bit 3]
  warning: host doesn't support requested feature: CPUID.07H:EBX.hle [bit 4]
  warning: host doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
  warning: host doesn't support requested feature: CPUID.07H:EBX.smep [bit 7]
  warning: host doesn't support requested feature: CPUID.07H:EBX.bmi2 [bit 8]
  warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9]
  warning: host doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 
10]
  warning: host doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11]
  [...]
  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=filtered-features
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 0
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 0
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 4025
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 356519936
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 0

Example output when no feature is missing:

  $ ./install/bin/qemu-system-x86_64 -enable-kvm -cpu Nehalem,enforce -S -qmp 
unix:/tmp/m,server,nowait
  [...]
  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1]
  --property=filtered-features
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 0
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 0
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 0
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 0
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 0

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 64e5570..0dceaf2 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1372,11 +1372,11 @@ static void x86_cpuid_set_tsc_freq(Object *obj, Visitor 
*v, void *opaque,
 cpu-env.tsc_khz = value / 1000;
 }
 
+/* Generic getter for feature-words and filtered-features properties */
 static void x86_cpu_get_feature_words(Object *obj, Visitor *v, void *opaque,
const char *name, Error **errp)
 {
-X86CPU *cpu = X86_CPU(obj);
-CPUX86State *env = cpu-env;
+uint32_t *array = (uint32_t *)opaque;
 FeatureWord w;
 Error *err = NULL;
 X86CPUFeatureWordInfo word_infos[FEATURE_WORDS] = { };
@@ -1390,7 +1390,7 @@ static void x86_cpu_get_feature_words(Object *obj, 
Visitor *v, void *opaque,
 qwi-has_cpuid_input_ecx = wi-cpuid_needs_ecx;
 qwi-cpuid_input_ecx = wi-cpuid_ecx;
 qwi-cpuid_register = x86_reg_info_32[wi-cpuid_reg].qapi_enum;
-qwi-features = env-features[w];
+qwi-features = array[w];
 
 /* List will be in reverse order, but order shouldn't matter */
 list_entries[w].next = list;
@@ -2354,7 +2354,10 @@ static void x86_cpu_initfn(Object *obj)
 x86_cpuid_set_tsc_freq, NULL, NULL, NULL);
 object_property_add(obj, feature-words, X86CPUFeatureWordInfo,
 x86_cpu_get_feature_words,
-NULL, NULL, NULL, NULL

[libvirt] [RFC 1/5] target-i386: Add ECX information to FeatureWordInfo

[Eduardo Habkost]

FEAT_7_0_EBX uses ECX as input, so we have to take that into account
when reporting feature word values.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index df6d6f0..6bb228b 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -151,8 +151,10 @@ static const char *cpuid_7_0_ebx_feature_name[] = {
 
 typedef struct FeatureWordInfo {
 const char **feat_names;
-uint32_t cpuid_eax; /* Input EAX for CPUID */
-int cpuid_reg;  /* R_* register constant */
+uint32_t cpuid_eax;   /* Input EAX for CPUID */
+bool cpuid_needs_ecx; /* CPUID instruction uses ECX as input */
+uint32_t cpuid_ecx;   /* Input ECX value for CPUID */
+int cpuid_reg;/* output register (R_* constant) */
 } FeatureWordInfo;
 
 static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
@@ -186,7 +188,9 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 },
 [FEAT_7_0_EBX] = {
 .feat_names = cpuid_7_0_ebx_feature_name,
-.cpuid_eax = 7, .cpuid_reg = R_EBX,
+.cpuid_eax = 7,
+.cpuid_needs_ecx = true, .cpuid_ecx = 0,
+.cpuid_reg = R_EBX,
 },
 };
 
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 0/5] X86CPU feature-words filtered-features properties (v2)

[Eduardo Habkost]

Changes v2:
 * Added filtered-features properties
 * Removed the non-qapi version and kept only the qapi version of the code
 * Moved the new types to qapi-schema.json instead of creating
   cpu-qapi-schema.json
 * Rebased on top of feature words array series

Git tree:
 https://github.com/ehabkost/qemu-hacks/tree/work/cpu-raw-feature-props-v2
 git://github.com/ehabkost/qemu-hacks.git work/cpu-raw-feature-props-v2

Description:

As the work to get X86CPU subclasses static properties defined is taking very
long to get reviewed and we risk not getting it finished in 1.5, I am sending
an alternative mechanism to allow libvirt to probe for CPU model information.

It's interesting to note that this alternative solution is actually _easier_ to
use for libvirt, because libvirt logic is already based on CPUID bit values, not
feature names, so it should be very easy to convert the current libvirt code
that (incorrectly) query the host CPU directly for available features to instead
start QEMU with -cpu host and use the feature-words array information to
find out which CPU features are supported by the host.

The feature-words property will have two main use cases:
 * Checking host capabilities, by checking the features of the host
   CPU model;
 * Checking which features are enabled on each CPU model.

The filtered-features property will have two main use cases:
 * Allowing libvirt to emulate the check  enforce flags while collecting
   more detailted data about the missing features;
 * Allowing libvirt to probe for CPU model information even if host features
   are missing (it can simply combine the feature-words and
   filtered-features values to get the full CPU model definition)

Example output:

  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=feature-words
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 1
  item[0].features: 126614521
  item[1].cpuid-register: ECX
  item[1].cpuid-input-eax: 1
  item[1].features: 2155880449
  item[2].cpuid-register: EBX
  item[2].cpuid-input-eax: 7
  item[2].features: 0
  item[2].cpuid-input-ecx: 0
  item[3].cpuid-register: EDX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 563346425
  item[4].cpuid-register: ECX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 101
  item[5].cpuid-register: EDX
  item[5].cpuid-input-eax: 3221225473
  item[5].features: 0
  item[6].cpuid-register: EAX
  item[6].cpuid-input-eax: 1073741825
  item[6].features: 0
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 2147483658
  item[7].features: 0


Eduardo Habkost (5):
  target-i386: Add ECX information to FeatureWordInfo
  target-i386: Add feature-words property
  target-i386: Use FeatureWord loop on filter_features_for_kvm()
  target-i386: Introduce X86CPU.filtered_features field
  target-i386: Add filtered-features property to X86CPU

 .gitignore|   2 +
 Makefile.objs |   7 +++-
 qapi-schema.json  |  32 +++
 target-i386/cpu-qom.h |   3 ++
 target-i386/cpu.c | 110 +++---
 5 files changed, 121 insertions(+), 33 deletions(-)

-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 3/5] target-i386: Use FeatureWord loop on filter_features_for_kvm()

[Eduardo Habkost]

Instead of open-coding the filtering code for each feature word, change
the existing code to use the feature_word_info array, that have exactly
the same CPUID eax/ecx/register values for each feature word.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu.c | 24 +++-
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 75ffc9e..3f4bcfd 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1637,24 +1637,14 @@ static void filter_features_for_kvm(X86CPU *cpu)
 {
 CPUX86State *env = cpu-env;
 KVMState *s = kvm_state;
+FeatureWord w;
 
-env-features[FEAT_1_EDX] =
-kvm_arch_get_supported_cpuid(s, 1, 0, R_EDX);
-env-features[FEAT_1_ECX] =
-kvm_arch_get_supported_cpuid(s, 1, 0, R_ECX);
-env-features[FEAT_8000_0001_EDX] =
-kvm_arch_get_supported_cpuid(s, 0x8001, 0, R_EDX);
-env-features[FEAT_8000_0001_ECX] =
-kvm_arch_get_supported_cpuid(s, 0x8001, 0, R_ECX);
-env-features[FEAT_SVM]  =
-kvm_arch_get_supported_cpuid(s, 0x800A, 0, R_EDX);
-env-features[FEAT_7_0_EBX] =
-kvm_arch_get_supported_cpuid(s, 7, 0, R_EBX);
-env-features[FEAT_KVM] =
-kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
-env-features[FEAT_C000_0001_EDX] =
-kvm_arch_get_supported_cpuid(s, 0xC001, 0, R_EDX);
-
+for (w = 0; w  FEATURE_WORDS; w++) {
+FeatureWordInfo *wi = feature_word_info[w];
+env-features[w] = kvm_arch_get_supported_cpuid(s, wi-cpuid_eax,
+wi-cpuid_ecx,
+wi-cpuid_reg);
+}
 }
 #endif
 
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [RFC 4/5] target-i386: Introduce X86CPU.filtered_features field

[Eduardo Habkost]

This field will contain the feature bits that were filtered out because
of missing host support.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu-qom.h | 3 +++
 target-i386/cpu.c | 9 ++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index 08f9eb6..159378f 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -65,6 +65,9 @@ typedef struct X86CPU {
 /* public */
 
 CPUX86State env;
+
+/* Features that were filtered out because of missing host capabilities */
+uint32_t filtered_features[FEATURE_WORDS];
 } X86CPU;
 
 static inline X86CPU *x86_env_get_cpu(CPUX86State *env)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 3f4bcfd..64e5570 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1641,9 +1641,12 @@ static void filter_features_for_kvm(X86CPU *cpu)
 
 for (w = 0; w  FEATURE_WORDS; w++) {
 FeatureWordInfo *wi = feature_word_info[w];
-env-features[w] = kvm_arch_get_supported_cpuid(s, wi-cpuid_eax,
-wi-cpuid_ecx,
-wi-cpuid_reg);
+uint32_t host_feat = kvm_arch_get_supported_cpuid(s, wi-cpuid_eax,
+ wi-cpuid_ecx,
+ wi-cpuid_reg);
+uint32_t requested_features = env-features[w];
+env-features[w] = host_feat;
+cpu-filtered_features[w] = requested_features  ~env-features[w];
 }
 }
 #endif
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qom-cpu 7/9] target-i386: Use FeatureWord loop on filter_features_for_kvm()

[Eduardo Habkost]

Instead of open-coding the filtering code for each feature word, change
the existing code to use the feature_word_info array, that have exactly
the same CPUID eax/ecx/register values for each feature word.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu.c | 24 +++-
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 757749c..bdb94a7 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1638,24 +1638,14 @@ static void filter_features_for_kvm(X86CPU *cpu)
 {
 CPUX86State *env = cpu-env;
 KVMState *s = kvm_state;
+FeatureWord w;
 
-env-features[FEAT_1_EDX] =
-kvm_arch_get_supported_cpuid(s, 1, 0, R_EDX);
-env-features[FEAT_1_ECX] =
-kvm_arch_get_supported_cpuid(s, 1, 0, R_ECX);
-env-features[FEAT_8000_0001_EDX] =
-kvm_arch_get_supported_cpuid(s, 0x8001, 0, R_EDX);
-env-features[FEAT_8000_0001_ECX] =
-kvm_arch_get_supported_cpuid(s, 0x8001, 0, R_ECX);
-env-features[FEAT_SVM]  =
-kvm_arch_get_supported_cpuid(s, 0x800A, 0, R_EDX);
-env-features[FEAT_7_0_EBX] =
-kvm_arch_get_supported_cpuid(s, 7, 0, R_EBX);
-env-features[FEAT_KVM] =
-kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
-env-features[FEAT_C000_0001_EDX] =
-kvm_arch_get_supported_cpuid(s, 0xC001, 0, R_EDX);
-
+for (w = 0; w  FEATURE_WORDS; w++) {
+FeatureWordInfo *wi = feature_word_info[w];
+env-features[w] = kvm_arch_get_supported_cpuid(s, wi-cpuid_eax,
+wi-cpuid_ecx,
+wi-cpuid_reg);
+}
 }
 #endif
 
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qom-cpu 0/9] x86: feature words array (v11) + feature-words property

[Eduardo Habkost]

This series includes the previous replace cpuid_*features fields with a feature
word array series.

The first 4 patches already have a Reviewed-by from Igor, they correspond to v10
plus a small indent fix requested by him.

As the cpuid_*features series was holding my feature-words/filtered-features
series (previously sent as RFC), I am now sending both as a single series, to
try to get feature-words/filtered-features some attention and try to get it
included in 1.5.

The feature-words/filtered-features mechanism is very important for libvirt,
to allow it to ensure the guest is getting the required set of CPU features, as
configured by the user.


Eduardo Habkost (9):
  target-i386: cleanup: Group together level, xlevel, xlevel2 fields
  target-i386/kvm.c: Code formatting changes
  target-i386/cpu.c: Break lines so they don't get too long
  target-i386: Replace cpuid_*features fields with a feature word array
  target-i386: Add ECX information to FeatureWordInfo
  target-i386: Add feature-words property
  target-i386: Use FeatureWord loop on filter_features_for_kvm()
  target-i386: Introduce X86CPU.filtered_features field
  target-i386: Add filtered-features property to X86CPU

 .gitignore|   2 +
 Makefile.objs |   7 +-
 bsd-user/elfload.c|   2 +-
 bsd-user/main.c   |   4 +-
 hw/i386/kvm/clock.c   |   2 +-
 linux-user/elfload.c  |   2 +-
 linux-user/main.c |   4 +-
 qapi-schema.json  |  31 +++
 target-i386/cpu-qom.h |   3 +
 target-i386/cpu.c | 501 +-
 target-i386/cpu.h |  15 +-
 target-i386/helper.c  |   4 +-
 target-i386/kvm.c |   5 +-
 target-i386/misc_helper.c |  14 +-
 target-i386/translate.c   |  10 +-
 15 files changed, 385 insertions(+), 221 deletions(-)

-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qom-cpu 6/9] target-i386: Add feature-words property

[Eduardo Habkost]

This property will be useful for libvirt, as libvirt already has logic
based on low-level feature bits (not feature names), so it will be
really easy to convert the current libvirt logic to something using the
feature-words property.

The property will have two main use cases:
 - Checking host capabilities, by checking the features of the host
   CPU model
 - Checking which features are enabled on each CPU model

Example output:

  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=feature-words
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 101
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 563346425
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 0
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 2155880449
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 126614521

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
Changes v1 - v2:
 * Merge the non-qapi and qapi patches, to keep series simpler
 * Use the feature word array series as base, so we don't have
   to set the feature word values one-by-one in the code
 * Change type name of property from x86-cpu-feature-words to
   X86CPUFeatureWordInfo
 * Remove cpu-qapi-schema.json and simply add the type definitions
   to qapi-schema.json, to keep the changes simpler
   * This required compiling qapi-types.o and qapi-visit.o into
 *-user as well
---
 .gitignore|  2 ++
 Makefile.objs |  7 +-
 qapi-schema.json  | 31 
 target-i386/cpu.c | 70 +--
 4 files changed, 97 insertions(+), 13 deletions(-)

diff --git a/.gitignore b/.gitignore
index 487813a..71408e3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -21,6 +21,8 @@ linux-headers/asm
 qapi-generated
 qapi-types.[ch]
 qapi-visit.[ch]
+cpu-qapi-types.[ch]
+cpu-qapi-visit.[ch]
 qmp-commands.h
 qmp-marshal.c
 qemu-doc.html
diff --git a/Makefile.objs b/Makefile.objs
index a473348..1835d37 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -78,10 +78,15 @@ common-obj-$(CONFIG_SMARTCARD_NSS) += $(libcacard-y)
 ##
 # qapi
 
-common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o
+common-obj-y += qmp-marshal.o
 common-obj-y += qmp.o hmp.o
 endif
 
+##
+# some qapi visitors are used by both system and user emulation:
+
+common-obj-y += qapi-visit.o qapi-types.o
+
 ###
 # Target-independent parts used in system and user emulation
 common-obj-y += qemu-log.o
diff --git a/qapi-schema.json b/qapi-schema.json
index 751d3c2..424434f 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3505,3 +3505,34 @@
 '*asl_compiler_rev':  'uint32',
 '*file':  'str',
 '*data':  'str' }}
+
+# @X86CPURegister32
+#
+# A X86 32-bit register
+#
+# Since: 1.5
+##
+{ 'enum': 'X86CPURegister32',
+  'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
+
+##
+# @X86CPUFeatureWordInfo
+#
+# Information about a X86 CPU feature word
+#
+# @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word
+#
+# @cpuid-input-ecx: #optional Input ECX value for CPUID instruction for that
+#   feature word
+#
+# @cpuid-register: Output register containing the feature bits
+#
+# @features: value of output register, containing the feature bits
+#
+# Since: 1.5
+##
+{ 'type': 'X86CPUFeatureWordInfo',
+  'data': { 'cpuid-input-eax': 'int',
+'*cpuid-input-ecx': 'int',
+'cpuid-register': 'X86CPURegister32',
+'features': 'int' } }
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 314931e..757749c 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -30,6 +30,8 @@
 #include qemu/config-file.h
 #include qapi/qmp/qerror.h
 
+#include qapi-types.h
+#include qapi-visit.h
 #include qapi/visitor.h
 #include sysemu/arch_init.h
 
@@ -194,23 +196,34 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 },
 };
 
+typedef struct X86RegisterInfo32 {
+/* Name of register */
+const char *name;
+/* QAPI enum value register */
+X86CPURegister32 qapi_enum;
+} X86RegisterInfo32;
+
+#define REGISTER(reg) \
+[R_##reg] = { .name = #reg, .qapi_enum = X86_C_P_U_REGISTER32_##reg }
+X86RegisterInfo32 x86_reg_info_32[CPU_NB_REGS32] = {
+REGISTER(EAX),
+REGISTER(ECX),
+REGISTER(EDX),
+REGISTER(EBX),
+REGISTER(ESP

[libvirt] [PATCH qom-cpu 9/9] target-i386: Add filtered-features property to X86CPU

[Eduardo Habkost]

This property will contain all the features that were removed from the
CPU because they are not supported by the host.

This way, libvirt or other management tools can emulate the
check/enforce behavior by checking if filtered-properties is all zeroes,
before starting the guest.

Example output where some features were missing:

  $ ./install/bin/qemu-system-x86_64 -enable-kvm -cpu Haswell,check -S -qmp 
unix:/tmp/m,server,nowait
  warning: host doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
  warning: host doesn't support requested feature: CPUID.01H:ECX.movbe [bit 22]
  warning: host doesn't support requested feature: CPUID.01H:ECX.tsc-deadline 
[bit 24]
  warning: host doesn't support requested feature: CPUID.01H:ECX.xsave [bit 26]
  warning: host doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
  warning: host doesn't support requested feature: CPUID.07H:EBX.fsgsbase [bit 
0]
  warning: host doesn't support requested feature: CPUID.07H:EBX.bmi1 [bit 3]
  warning: host doesn't support requested feature: CPUID.07H:EBX.hle [bit 4]
  warning: host doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
  warning: host doesn't support requested feature: CPUID.07H:EBX.smep [bit 7]
  warning: host doesn't support requested feature: CPUID.07H:EBX.bmi2 [bit 8]
  warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9]
  warning: host doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 
10]
  warning: host doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11]
  [...]
  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=filtered-features
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 0
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 0
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 4025
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 356519936
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 0

Example output when no feature is missing:

  $ ./install/bin/qemu-system-x86_64 -enable-kvm -cpu Nehalem,enforce -S -qmp 
unix:/tmp/m,server,nowait
  [...]
  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1]
  --property=filtered-features
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 0
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 0
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 0
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 0
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 0

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 1178c5f..5bcb79c 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1373,11 +1373,11 @@ static void x86_cpuid_set_tsc_freq(Object *obj, Visitor 
*v, void *opaque,
 cpu-env.tsc_khz = value / 1000;
 }
 
+/* Generic getter for feature-words and filtered-features properties */
 static void x86_cpu_get_feature_words(Object *obj, Visitor *v, void *opaque,
const char *name, Error **errp)
 {
-X86CPU *cpu = X86_CPU(obj);
-CPUX86State *env = cpu-env;
+uint32_t *array = (uint32_t *)opaque;
 FeatureWord w;
 Error *err = NULL;
 X86CPUFeatureWordInfo word_infos[FEATURE_WORDS] = { };
@@ -1391,7 +1391,7 @@ static void x86_cpu_get_feature_words(Object *obj, 
Visitor *v, void *opaque,
 qwi-has_cpuid_input_ecx = wi-cpuid_needs_ecx;
 qwi-cpuid_input_ecx = wi-cpuid_ecx;
 qwi-cpuid_register = x86_reg_info_32[wi-cpuid_reg].qapi_enum;
-qwi-features = env-features[w];
+qwi-features = array[w];
 
 /* List will be in reverse order, but order shouldn't matter */
 list_entries[w].next = list;
@@ -2386,7 +2386,10 @@ static void x86_cpu_initfn(Object *obj)
 x86_cpuid_set_tsc_freq, NULL, NULL, NULL);
 object_property_add(obj, feature-words, X86CPUFeatureWordInfo,
 x86_cpu_get_feature_words,
-NULL, NULL, NULL, NULL

[libvirt] [PATCH qom-cpu 5/9] target-i386: Add ECX information to FeatureWordInfo

[Eduardo Habkost]

FEAT_7_0_EBX uses ECX as input, so we have to take that into account
when reporting feature word values.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 110ef98..314931e 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -151,8 +151,10 @@ static const char *cpuid_7_0_ebx_feature_name[] = {
 
 typedef struct FeatureWordInfo {
 const char **feat_names;
-uint32_t cpuid_eax; /* Input EAX for CPUID */
-int cpuid_reg;  /* R_* register constant */
+uint32_t cpuid_eax;   /* Input EAX for CPUID */
+bool cpuid_needs_ecx; /* CPUID instruction uses ECX as input */
+uint32_t cpuid_ecx;   /* Input ECX value for CPUID */
+int cpuid_reg;/* output register (R_* constant) */
 } FeatureWordInfo;
 
 static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
@@ -186,7 +188,9 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 },
 [FEAT_7_0_EBX] = {
 .feat_names = cpuid_7_0_ebx_feature_name,
-.cpuid_eax = 7, .cpuid_reg = R_EBX,
+.cpuid_eax = 7,
+.cpuid_needs_ecx = true, .cpuid_ecx = 0,
+.cpuid_reg = R_EBX,
 },
 };
 
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qom-cpu 1/9] target-i386: cleanup: Group together level, xlevel, xlevel2 fields

[Eduardo Habkost]

Consolidate level, xlevel, xlevel2 fields in x86_def_t and CPUX86State.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-By: Igor Mammedov imamm...@redhat.com
---
Changes v9:
 * Merged target-i386: Move cpuid_xlevel, cpuid_xlevel2 fields in X86CPU
   and target-i386: Move xlevel/xlevel2 in struct x86_def_t
   in a single patch
---
 target-i386/cpu.c | 4 ++--
 target-i386/cpu.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index e2302d8..732cafd 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -349,6 +349,8 @@ static void add_flagname_to_bitmaps(const char *flagname,
 typedef struct x86_def_t {
 const char *name;
 uint32_t level;
+uint32_t xlevel;
+uint32_t xlevel2;
 /* vendor is zero-terminated, 12 character ASCII string */
 char vendor[CPUID_VENDOR_SZ + 1];
 int family;
@@ -356,11 +358,9 @@ typedef struct x86_def_t {
 int stepping;
 uint32_t features, ext_features, ext2_features, ext3_features;
 uint32_t kvm_features, svm_features;
-uint32_t xlevel;
 char model_id[48];
 /* Store the results of Centaur's CPUID instructions */
 uint32_t ext4_features;
-uint32_t xlevel2;
 /* The feature bits on CPUID[EAX=7,ECX=0].EBX */
 uint32_t cpuid_7_0_ebx_features;
 } x86_def_t;
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index a1614e8..c621359 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -836,19 +836,19 @@ typedef struct CPUX86State {
 
 /* processor features (e.g. for CPUID insn) */
 uint32_t cpuid_level;
+uint32_t cpuid_xlevel;
+uint32_t cpuid_xlevel2;
 uint32_t cpuid_vendor1;
 uint32_t cpuid_vendor2;
 uint32_t cpuid_vendor3;
 uint32_t cpuid_version;
 uint32_t cpuid_features;
 uint32_t cpuid_ext_features;
-uint32_t cpuid_xlevel;
 uint32_t cpuid_model[12];
 uint32_t cpuid_ext2_features;
 uint32_t cpuid_ext3_features;
 uint32_t cpuid_apic_id;
 /* Store the results of Centaur's CPUID instructions */
-uint32_t cpuid_xlevel2;
 uint32_t cpuid_ext4_features;
 /* Flags from CPUID[EAX=7,ECX=0].EBX */
 uint32_t cpuid_7_0_ebx_features;
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qom-cpu 2/9] target-i386/kvm.c: Code formatting changes

[Eduardo Habkost]

Add appropriate spaces around operators, and break line where it needs
to be broken to allow feature-words array to be introduced without
having too-long lines.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-By: Igor Mammedov imamm...@redhat.com
---
Changes v9:
 * 1-char alignment change: keep the opening parenthesis of both sides
   of the == operator starting at the same column
---
 target-i386/kvm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 0e7cc81..b5bff33 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -613,7 +613,8 @@ int kvm_arch_init_vcpu(CPUState *cs)
 cpuid_data.cpuid.nent = cpuid_i;
 
 if (((env-cpuid_version  8)0xF) = 6
- (env-cpuid_features(CPUID_MCE|CPUID_MCA)) == (CPUID_MCE|CPUID_MCA)
+ (env-cpuid_features  (CPUID_MCE|CPUID_MCA)) ==
+   (CPUID_MCE|CPUID_MCA)
  kvm_check_extension(cs-kvm_state, KVM_CAP_MCE)  0) {
 uint64_t mcg_cap;
 int banks;
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qom-cpu 3/9] target-i386/cpu.c: Break lines so they don't get too long

[Eduardo Habkost]

Break lines on kvm_check_features_against_host(), kvm_cpu_fill_host(),
and builtin_x86_defs, so they don't get too long once the *_features
fields are replaced by an array.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-By: Igor Mammedov imamm...@redhat.com
---
Changes v9:
 * Merged all Break lines patches from previous series into a single
   patch
---
 target-i386/cpu.c | 270 --
 1 file changed, 180 insertions(+), 90 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 732cafd..73ae2ef 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -423,13 +423,17 @@ static x86_def_t builtin_x86_defs[] = {
 .family = 6,
 .model = 2,
 .stepping = 3,
-.features = PPRO_FEATURES |
+.features =
+PPRO_FEATURES |
 CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
 CPUID_PSE36,
-.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_POPCNT,
-.ext2_features = (PPRO_FEATURES  CPUID_EXT2_AMD_ALIASES) |
+.ext_features =
+CPUID_EXT_SSE3 | CPUID_EXT_CX16 | CPUID_EXT_POPCNT,
+.ext2_features =
+(PPRO_FEATURES  CPUID_EXT2_AMD_ALIASES) |
 CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
-.ext3_features = CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM |
+.ext3_features =
+CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM |
 CPUID_EXT3_ABM | CPUID_EXT3_SSE4A,
 .xlevel = 0x800A,
 },
@@ -440,12 +444,15 @@ static x86_def_t builtin_x86_defs[] = {
 .family = 16,
 .model = 2,
 .stepping = 3,
-.features = PPRO_FEATURES |
+.features =
+PPRO_FEATURES |
 CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
 CPUID_PSE36 | CPUID_VME | CPUID_HT,
-.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR | CPUID_EXT_CX16 |
+.ext_features =
+CPUID_EXT_SSE3 | CPUID_EXT_MONITOR | CPUID_EXT_CX16 |
 CPUID_EXT_POPCNT,
-.ext2_features = (PPRO_FEATURES  CPUID_EXT2_AMD_ALIASES) |
+.ext2_features =
+(PPRO_FEATURES  CPUID_EXT2_AMD_ALIASES) |
 CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX |
 CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT | CPUID_EXT2_MMXEXT |
 CPUID_EXT2_FFXSR | CPUID_EXT2_PDPE1GB | CPUID_EXT2_RDTSCP,
@@ -453,9 +460,11 @@ static x86_def_t builtin_x86_defs[] = {
 CPUID_EXT3_CR8LEG,
 CPUID_EXT3_MISALIGNSSE, CPUID_EXT3_3DNOWPREFETCH,
 CPUID_EXT3_OSVW, CPUID_EXT3_IBS */
-.ext3_features = CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM |
+.ext3_features =
+CPUID_EXT3_LAHF_LM | CPUID_EXT3_SVM |
 CPUID_EXT3_ABM | CPUID_EXT3_SSE4A,
-.svm_features = CPUID_SVM_NPT | CPUID_SVM_LBRV,
+.svm_features =
+CPUID_SVM_NPT | CPUID_SVM_LBRV,
 .xlevel = 0x801A,
 .model_id = AMD Phenom(tm) 9550 Quad-Core Processor
 },
@@ -466,15 +475,19 @@ static x86_def_t builtin_x86_defs[] = {
 .family = 6,
 .model = 15,
 .stepping = 11,
-.features = PPRO_FEATURES |
+.features =
+PPRO_FEATURES |
 CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
 CPUID_PSE36 | CPUID_VME | CPUID_DTS | CPUID_ACPI | CPUID_SS |
 CPUID_HT | CPUID_TM | CPUID_PBE,
-.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR | CPUID_EXT_SSSE3 |
+.ext_features =
+CPUID_EXT_SSE3 | CPUID_EXT_MONITOR | CPUID_EXT_SSSE3 |
 CPUID_EXT_DTES64 | CPUID_EXT_DSCPL | CPUID_EXT_VMX | CPUID_EXT_EST 
|
 CPUID_EXT_TM2 | CPUID_EXT_CX16 | CPUID_EXT_XTPR | CPUID_EXT_PDCM,
-.ext2_features = CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
-.ext3_features = CPUID_EXT3_LAHF_LM,
+.ext2_features =
+CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
+.ext3_features =
+CPUID_EXT3_LAHF_LM,
 .xlevel = 0x8008,
 .model_id = Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz,
 },
@@ -486,19 +499,23 @@ static x86_def_t builtin_x86_defs[] = {
 .model = 6,
 .stepping = 1,
 /* Missing: CPUID_VME, CPUID_HT */
-.features = PPRO_FEATURES |
+.features =
+PPRO_FEATURES |
 CPUID_MTRR | CPUID_CLFLUSH | CPUID_MCA |
 CPUID_PSE36,
 /* Missing: CPUID_EXT_POPCNT, CPUID_EXT_MONITOR */
-.ext_features = CPUID_EXT_SSE3 | CPUID_EXT_CX16,
+.ext_features =
+CPUID_EXT_SSE3 | CPUID_EXT_CX16,
 /* Missing: CPUID_EXT2_PDPE1GB, CPUID_EXT2_RDTSCP */
-.ext2_features = (PPRO_FEATURES  CPUID_EXT2_AMD_ALIASES) |
+.ext2_features =
+(PPRO_FEATURES  CPUID_EXT2_AMD_ALIASES) |
 CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
 /* Missing: CPUID_EXT3_LAHF_LM

[libvirt] [PATCH qom-cpu 8/9] target-i386: Introduce X86CPU.filtered_features field

[Eduardo Habkost]

This field will contain the feature bits that were filtered out because
of missing host support.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
---
 target-i386/cpu-qom.h | 3 +++
 target-i386/cpu.c | 9 ++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index 08f9eb6..159378f 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -65,6 +65,9 @@ typedef struct X86CPU {
 /* public */
 
 CPUX86State env;
+
+/* Features that were filtered out because of missing host capabilities */
+uint32_t filtered_features[FEATURE_WORDS];
 } X86CPU;
 
 static inline X86CPU *x86_env_get_cpu(CPUX86State *env)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index bdb94a7..1178c5f 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1642,9 +1642,12 @@ static void filter_features_for_kvm(X86CPU *cpu)
 
 for (w = 0; w  FEATURE_WORDS; w++) {
 FeatureWordInfo *wi = feature_word_info[w];
-env-features[w] = kvm_arch_get_supported_cpuid(s, wi-cpuid_eax,
-wi-cpuid_ecx,
-wi-cpuid_reg);
+uint32_t host_feat = kvm_arch_get_supported_cpuid(s, wi-cpuid_eax,
+ wi-cpuid_ecx,
+ wi-cpuid_reg);
+uint32_t requested_features = env-features[w];
+env-features[w] = host_feat;
+cpu-filtered_features[w] = requested_features  ~env-features[w];
 }
 }
 #endif
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH qom-cpu 6/9] target-i386: Add feature-words property

[Eduardo Habkost]

On Mon, Apr 22, 2013 at 02:37:06PM -0600, Eric Blake wrote:
 On 04/22/2013 01:00 PM, Eduardo Habkost wrote:
  This property will be useful for libvirt, as libvirt already has logic
  based on low-level feature bits (not feature names), so it will be
  really easy to convert the current libvirt logic to something using the
  feature-words property.
  
  The property will have two main use cases:
   - Checking host capabilities, by checking the features of the host
 CPU model
   - Checking which features are enabled on each CPU model
  
  Example output:
  
$ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
  --property=feature-words
 
 If I'm not mistaken, the QMP counterpart that libvirt will use is:
 
 { execute:qom-get,
   arguments: { path:/machine/unattached/device[1],
  property:feature-words } }

Yes, but note that libvirt needs to look for the X86CPU objects, to find
the actual path as there's no guarantee that it will always be
/machine/unattached/devices[1]. Maybe the CPU hotplug work will end up
offering a predictable path for the X86CPU objects, but this is not
available yet.

 
item[0].cpuid-register: EDX
item[0].cpuid-input-eax: 2147483658
item[0].features: 0
item[1].cpuid-register: EAX
item[1].cpuid-input-eax: 1073741825
item[1].features: 0
item[2].cpuid-register: EDX
item[2].cpuid-input-eax: 3221225473
item[2].features: 0
item[3].cpuid-register: ECX
item[3].cpuid-input-eax: 2147483649
item[3].features: 101
item[4].cpuid-register: EDX
item[4].cpuid-input-eax: 2147483649
item[4].features: 563346425
item[5].cpuid-register: EBX
item[5].cpuid-input-eax: 7
item[5].features: 0
item[5].cpuid-input-ecx: 0
item[6].cpuid-register: ECX
item[6].cpuid-input-eax: 1
item[6].features: 2155880449
item[7].cpuid-register: EDX
item[7].cpuid-input-eax: 1
item[7].features: 126614521
 
 And this would then be returned as a JSON array containing struct
 members looking like this:
 
  +{ 'type': 'X86CPUFeatureWordInfo',
  +  'data': { 'cpuid-input-eax': 'int',
  +'*cpuid-input-ecx': 'int',
  +'cpuid-register': 'X86CPURegister32',
  +'features': 'int' } }

Yes.

 
 Looks reasonable (and better than what we've had in the past!), although
 I'll let Jiri Denemark give final say on whether it meets libvirt's needs.

Thanks for the feedback!

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/4] QMP: add cpu-add command

[Eduardo Habkost]

(CCing libvir-list)

On Tue, Apr 30, 2013 at 08:34:01AM +0200, Igor Mammedov wrote:
 Adds cpu-add id=xxx QMP command.
 
 cpu-add's id argument is a CPU number in a range [0..max-cpus)
 
 Example QMP command:
  - { execute: cpu-add, arguments: { id: 2 } }
  - { return: {} }
 
 Signed-off-by: Igor Mammedov imamm...@redhat.com
 Acked-by: Luiz Capitulino lcapitul...@redhat.com
 Reviewed-by: Eric Blake ebl...@redhat.com

The only way to find out if CPU hotplug is really available on a given
machine-type is by actually trying to run cpu-add, right? Is this
sufficient for libvirt requirements?


 ---
 v7:
   * added Since 1.5 to cpu-add qapi schema definition
 v6:
   * added valid values description to qapi schema
   * split out cpu_hot_add hooks introduction into separate patch
   * split out implementation of cpu_hot_add for target-i386
 v5:
   * accept id=[0..max_cpus) range in cpu-add command
 v4:
   * merge qmp: add cpu-add qmp command  target-i386: implement CPU 
 hot-add patches
   * move notifier call to CPUCLass.realize()
   * add hook cpu_hot_add to QEMUMachine
   * make QEMUMachineInitArgs global and keep default cpu_model there
 
 v3:
   * it appears that 'online/offline' in cpu-set are confusing people
 with what command actually does and users might have to distinguish
 if 'offline' is not implemented by parsing error message. To simplify
 things replace cpu-set with cpu-add command to show more clear what
 command does and just add cpu-del when CPU remove is implemented.
 
 v2:
   * s/cpu_set/cpu-set/
   * qmp doc style fix
   * use bool type instead of opencodding online/offline string
  suggested-by: Eric Blake ebl...@redhat.com
 ---
  qapi-schema.json | 13 +
  qmp-commands.hx  | 23 +++
  qmp.c| 10 ++
  3 files changed, 46 insertions(+)
 
 diff --git a/qapi-schema.json b/qapi-schema.json
 index 5b0fb3b..6f58b0f 100644
 --- a/qapi-schema.json
 +++ b/qapi-schema.json
 @@ -1387,6 +1387,19 @@
  { 'command': 'cpu', 'data': {'index': 'int'} }
  
  ##
 +# @cpu-add
 +#
 +# Adds CPU with specified ID
 +#
 +# @id: ID of CPU to be created, valid values [0..max_cpus)
 +#
 +# Returns: Nothing on success
 +#
 +# Since 1.5
 +##
 +{ 'command': 'cpu-add', 'data': {'id': 'int'} }
 +
 +##
  # @memsave:
  #
  # Save a portion of guest memory to a file.
 diff --git a/qmp-commands.hx b/qmp-commands.hx
 index 0e89132..ed99eb8 100644
 --- a/qmp-commands.hx
 +++ b/qmp-commands.hx
 @@ -385,6 +385,29 @@ Note: CPUs' indexes are obtained with the 'query-cpus' 
 command.
  EQMP
  
  {
 +.name   = cpu-add,
 +.args_type  = id:i,
 +.mhandler.cmd_new = qmp_marshal_input_cpu_add,
 +},
 +
 +SQMP
 +cpu-add
 +---
 +
 +Adds virtual cpu
 +
 +Arguments:
 +
 +- id: cpu id (json-int)
 +
 +Example:
 +
 +- { execute: cpu-add, arguments: { id: 2 } }
 +- { return: {} }
 +
 +EQMP
 +
 +{
  .name   = memsave,
  .args_type  = val:l,size:i,filename:s,cpu:i?,
  .mhandler.cmd_new = qmp_marshal_input_memsave,
 diff --git a/qmp.c b/qmp.c
 index ed6c7ef..dd34be6 100644
 --- a/qmp.c
 +++ b/qmp.c
 @@ -24,6 +24,7 @@
  #include hw/qdev.h
  #include sysemu/blockdev.h
  #include qom/qom-qobject.h
 +#include hw/boards.h
  
  NameInfo *qmp_query_name(Error **errp)
  {
 @@ -108,6 +109,15 @@ void qmp_cpu(int64_t index, Error **errp)
  /* Just do nothing */
  }
  
 +void qmp_cpu_add(int64_t id, Error **errp)
 +{
 +if (current_machine-hot_add_cpu) {
 +current_machine-hot_add_cpu(id, errp);
 +} else {
 +error_setg(errp, Not supported);
 +}
 +}
 +
  #ifndef CONFIG_VNC
  /* If VNC support is enabled, the true query-vnc command is
 defined in the VNC subsystem */
 -- 
 1.8.2.1
 

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH qom-cpu 4/9] target-i386: Replace cpuid_*features fields with a feature word array

[Eduardo Habkost]

On Thu, May 02, 2013 at 01:03:01AM +0200, Andreas Färber wrote:
 Am 22.04.2013 21:00, schrieb Eduardo Habkost:
  This replaces the feature-bit fields on both X86CPU and x86_def_t
  structs with an array.
  
  With this, we will be able to simplify code that simply does the same
  operation on all feature words (e.g. kvm_check_features_against_host(),
  filter_features_for_kvm(), add_flagname_to_bitmaps(), CPU feature-bit
  property lookup/registration, and the proposed feature-words property)
  
  The following field replacements were made on X86CPU and x86_def_t:
  
(cpuid_)features - features[FEAT_1_EDX]
(cpuid_)ext_features - features[FEAT_1_ECX]
(cpuid_)ext2_features- features[FEAT_8000_0001_EDX]
(cpuid_)ext3_features- features[FEAT_8000_0001_ECX]
(cpuid_)ext4_features- features[FEAT_C000_0001_EDX]
(cpuid_)kvm_features - features[FEAT_KVM]
(cpuid_)svm_features - features[FEAT_SVM]
(cpuid_)7_0_ebx_features - features[FEAT_7_0_EBX]
  
  Signed-off-by: Eduardo Habkost ehabk...@redhat.com
  Reviewed-By: Igor Mammedov imamm...@redhat.com
 [...]
  diff --git a/target-i386/cpu.c b/target-i386/cpu.c
  index 73ae2ef..110ef98 100644
  --- a/target-i386/cpu.c
  +++ b/target-i386/cpu.c
 [...]
  @@ -1490,22 +1485,22 @@ static void cpu_x86_parse_featurestr(X86CPU *cpu, 
  char *features, Error **errp)
   }
   featurestr = strtok(NULL, ,);
   }
  -env-cpuid_features |= plus_features[FEAT_1_EDX];
  -env-cpuid_ext_features |= plus_features[FEAT_1_ECX];
  -env-cpuid_ext2_features |= plus_features[FEAT_8000_0001_EDX];
  -env-cpuid_ext3_features |= plus_features[FEAT_8000_0001_ECX];
  -env-cpuid_ext4_features |= plus_features[FEAT_C000_0001_EDX];
  -env-cpuid_kvm_features |= plus_features[FEAT_KVM];
  -env-cpuid_svm_features |= plus_features[FEAT_SVM];
  -env-cpuid_7_0_ebx_features |= plus_features[FEAT_7_0_EBX];
  -env-cpuid_features = ~minus_features[FEAT_1_EDX];
  -env-cpuid_ext_features = ~minus_features[FEAT_1_ECX];
  -env-cpuid_ext2_features = ~minus_features[FEAT_8000_0001_EDX];
  -env-cpuid_ext3_features = ~minus_features[FEAT_8000_0001_ECX];
  -env-cpuid_ext4_features = ~minus_features[FEAT_C000_0001_EDX];
  -env-cpuid_kvm_features = ~minus_features[FEAT_KVM];
  -env-cpuid_svm_features = ~minus_features[FEAT_SVM];
  -env-cpuid_7_0_ebx_features = ~minus_features[FEAT_7_0_EBX];
  +env-features[FEAT_1_EDX] |= plus_features[FEAT_1_EDX];
  +env-features[FEAT_1_ECX] |= plus_features[FEAT_1_ECX];
  +env-features[FEAT_8000_0001_EDX] |= plus_features[FEAT_8000_0001_EDX];
  +env-features[FEAT_8000_0001_ECX] |= plus_features[FEAT_8000_0001_ECX];
  +env-features[FEAT_C000_0001_EDX] |= plus_features[FEAT_C000_0001_EDX];
  +env-features[FEAT_KVM] |= plus_features[FEAT_KVM];
  +env-features[FEAT_SVM] |= plus_features[FEAT_SVM];
  +env-features[FEAT_7_0_EBX] |= plus_features[FEAT_7_0_EBX];
  +env-features[FEAT_1_EDX] = ~minus_features[FEAT_1_EDX];
  +env-features[FEAT_1_ECX] = ~minus_features[FEAT_1_ECX];
  +env-features[FEAT_8000_0001_EDX] = 
  ~minus_features[FEAT_8000_0001_EDX];
  +env-features[FEAT_8000_0001_ECX] = 
  ~minus_features[FEAT_8000_0001_ECX];
  +env-features[FEAT_C000_0001_EDX] = 
  ~minus_features[FEAT_C000_0001_EDX];
  +env-features[FEAT_KVM] = ~minus_features[FEAT_KVM];
  +env-features[FEAT_SVM] = ~minus_features[FEAT_SVM];
  +env-features[FEAT_7_0_EBX] = ~minus_features[FEAT_7_0_EBX];
   
   out:
   return;
 
 Can this be done in a loop as a follow-up?

Yes, that was exactly the plan. :-)

But it's something to be done after 1.5, I guess?

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH qom-cpu 0/9] x86: feature words array (v11) + feature-words property

[Eduardo Habkost]

On Thu, May 02, 2013 at 12:53:33AM +0200, Andreas Färber wrote:
  Eduardo Habkost (9):
target-i386: cleanup: Group together level, xlevel, xlevel2 fields
target-i386/kvm.c: Code formatting changes
target-i386/cpu.c: Break lines so they don't get too long
target-i386: Replace cpuid_*features fields with a feature word array
 
 Thanks, applied these to qom-cpu:
 https://github.com/afaerber/qemu-cpu/commits/qom-cpu
 
 These had been around for quite some time and I have reviewed the first
 three line by line; for the fourth I have looked at the script sources
 and trust Igor's review. Thanks for repeatedly rebasing this, Eduardo!

Thanks!

 
 
target-i386: Add ECX information to FeatureWordInfo
 
 This one is lacking Reviewed-by / Acked-by ...
 
target-i386: Add feature-words property
target-i386: Use FeatureWord loop on filter_features_for_kvm()
 
 ... and this one seems to depend on it.
 
target-i386: Introduce X86CPU.filtered_features field
target-i386: Add filtered-features property to X86CPU
 
 As mentioned earlier I'd prefer to defer the property design rather than
 putting it lightly reviewed into 1.5 and living with some ABI.
 If libvirt urgently needs this info, this series needs to be reviewed
 and sorted out until the weekend (Hard Freeze on Monday).

I consider it an important bugfix for the QEMU+libvirt stack. The
current libvirt behavior (checking CPUID directly; not using the
enforce flag; and having its own copy of each CPU model definition) is
unsafe and may break live-migration silently under many circumstances.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH qom-cpu 6/9] target-i386: Add feature-words property

[Eduardo Habkost]

On Fri, May 03, 2013 at 01:34:23PM +0200, Igor Mammedov wrote:
 On Mon, 22 Apr 2013 16:00:17 -0300
 Eduardo Habkost ehabk...@redhat.com wrote:
 
  This property will be useful for libvirt, as libvirt already has logic
  based on low-level feature bits (not feature names), so it will be
  really easy to convert the current libvirt logic to something using the
  feature-words property.
  
  The property will have two main use cases:
   - Checking host capabilities, by checking the features of the host
 CPU model
   - Checking which features are enabled on each CPU model
 
 patch doesn't apply to current qom-cpu, more comments below.
 
  
  Example output:
  
$ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
  --property=feature-words
item[0].cpuid-register: EDX
item[0].cpuid-input-eax: 2147483658
item[0].features: 0
item[1].cpuid-register: EAX
item[1].cpuid-input-eax: 1073741825
item[1].features: 0
item[2].cpuid-register: EDX
item[2].cpuid-input-eax: 3221225473
item[2].features: 0
item[3].cpuid-register: ECX
item[3].cpuid-input-eax: 2147483649
item[3].features: 101
item[4].cpuid-register: EDX
item[4].cpuid-input-eax: 2147483649
item[4].features: 563346425
item[5].cpuid-register: EBX
item[5].cpuid-input-eax: 7
item[5].features: 0
item[5].cpuid-input-ecx: 0
 could item be represented as CPUID function in format used in Intel's SDM?
 

We could, but maybe it would make the interface harder to use and not
easier?

Even when two feature words are returned in the same CPUID leaf, they
are independent and separate feature-words that must be checked
individually by libvirt, so I believe returning one feature-word per
array-item makes more sense. Having an extra item in the array would
make it clear for libvirt that QEMU has a new feature-word that libvirt
doesn't know about, and easier to spot than an extra field in an
existing array item.


 item[5].CPUID: EAX=7h,ECX=0h

What would be the data type of this CPUID field? Are you suggesting
returning a string to be parsed manually?


 item[5].EBX: 0
 item[5].EAX: 0
 
 for simplicity/uniformity ECX could be not optional, always present, and
 ignored when not needed.

Then how would we represent the fact that ECX is optional? If ECX is not
important for a given CPUID leaf, I don't see what's the point of
including it with a fake value.

Note that this interface is not supposed to be a comprehensive CPUID
dump with all CPUID bits returned by the CPU, but just a list of CPU
capability words that happen to be returned inside CPUID leaves.

  
item[6].cpuid-register: ECX
item[6].cpuid-input-eax: 1
item[6].features: 2155880449
item[7].cpuid-register: EDX
item[7].cpuid-input-eax: 1
item[7].features: 126614521
  
  Signed-off-by: Eduardo Habkost ehabk...@redhat.com
  ---
  Changes v1 - v2:
   * Merge the non-qapi and qapi patches, to keep series simpler
   * Use the feature word array series as base, so we don't have
 to set the feature word values one-by-one in the code
   * Change type name of property from x86-cpu-feature-words to
 X86CPUFeatureWordInfo
   * Remove cpu-qapi-schema.json and simply add the type definitions
 to qapi-schema.json, to keep the changes simpler
 * This required compiling qapi-types.o and qapi-visit.o into
   *-user as well
  ---
   .gitignore|  2 ++
   Makefile.objs |  7 +-
   qapi-schema.json  | 31 
   target-i386/cpu.c | 70 
  +--
   4 files changed, 97 insertions(+), 13 deletions(-)
  
  diff --git a/.gitignore b/.gitignore
  index 487813a..71408e3 100644
  --- a/.gitignore
  +++ b/.gitignore
  @@ -21,6 +21,8 @@ linux-headers/asm
   qapi-generated
   qapi-types.[ch]
   qapi-visit.[ch]
  +cpu-qapi-types.[ch]
  +cpu-qapi-visit.[ch]
 still needed?

Not needed anymore. Thanks for spotting it.

 
   qmp-commands.h
   qmp-marshal.c
   qemu-doc.html
  diff --git a/Makefile.objs b/Makefile.objs
  index a473348..1835d37 100644
  --- a/Makefile.objs
  +++ b/Makefile.objs
  @@ -78,10 +78,15 @@ common-obj-$(CONFIG_SMARTCARD_NSS) += $(libcacard-y)
   ##
   # qapi
   
  -common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o
  +common-obj-y += qmp-marshal.o
   common-obj-y += qmp.o hmp.o
   endif
   
  +##
  +# some qapi visitors are used by both system and user emulation:
  +
  +common-obj-y += qapi-visit.o qapi-types.o
  +
   ###
   # Target-independent parts used in system and user emulation
   common-obj-y += qemu-log.o
  diff --git a/qapi-schema.json b/qapi-schema.json
  index 751d3c2..424434f 100644
  --- a/qapi-schema.json
  +++ b/qapi-schema.json
  @@ -3505,3 +3505,34 @@
   '*asl_compiler_rev':  'uint32

Re: [libvirt] [Qemu-devel] [PATCH qom-cpu 5/9] target-i386: Add ECX information to FeatureWordInfo

[Eduardo Habkost]

On Fri, May 03, 2013 at 05:16:46PM +0200, Andreas Färber wrote:
 Am 22.04.2013 21:00, schrieb Eduardo Habkost:
  FEAT_7_0_EBX uses ECX as input, so we have to take that into account
  when reporting feature word values.
  
  Signed-off-by: Eduardo Habkost ehabk...@redhat.com
  ---
   target-i386/cpu.c | 10 +++---
   1 file changed, 7 insertions(+), 3 deletions(-)
  
  diff --git a/target-i386/cpu.c b/target-i386/cpu.c
  index 110ef98..314931e 100644
  --- a/target-i386/cpu.c
  +++ b/target-i386/cpu.c
  @@ -151,8 +151,10 @@ static const char *cpuid_7_0_ebx_feature_name[] = {
   
   typedef struct FeatureWordInfo {
   const char **feat_names;
  -uint32_t cpuid_eax; /* Input EAX for CPUID */
  -int cpuid_reg;  /* R_* register constant */
  +uint32_t cpuid_eax;   /* Input EAX for CPUID */
 
  +bool cpuid_needs_ecx; /* CPUID instruction uses ECX as input */
 
 Why do we need this needs_ field here? eax and reg just seem to be
 reindented and the comment reworded for reg.

We need it so we know if ECX is used as input on that CPUID leaf, in
other words: so we know if cpuid-input-ecx needs to be set on
X86CPUFeatureWordInfo or not.

cpuid-input-ecx is optional because most CPUID leafs don't depend on
input ECX value, only EAX. cpuid_needs_ecx has a similar meaning to
KVM_CPUID_FLAG_SIGNIFCANT_INDEX on kvm_cpuid_entry2.flags.

 
 It just seems to be passed through to has_cpuid_input_ecx, which I
 neither see defined nor checked - that data structure already existed
 elsewhere as such?

X86CPUFeatureWordInfo is generated from the QAPI schema.

 
 Andreas
 
  +uint32_t cpuid_ecx;   /* Input ECX value for CPUID */
  +int cpuid_reg;/* output register (R_* constant) */
   } FeatureWordInfo;
   
   static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
  @@ -186,7 +188,9 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] 
  = {
   },
   [FEAT_7_0_EBX] = {
   .feat_names = cpuid_7_0_ebx_feature_name,
  -.cpuid_eax = 7, .cpuid_reg = R_EBX,
  +.cpuid_eax = 7,
  +.cpuid_needs_ecx = true, .cpuid_ecx = 0,
  +.cpuid_reg = R_EBX,
   },
   };
   
  
 
 
 -- 
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qom-cpu-next 1/3] target-i386: Add feature-words property

[Eduardo Habkost]

This property will be useful for libvirt, as libvirt already has logic
based on low-level feature bits (not feature names), so it will be
really easy to convert the current libvirt logic to something using the
feature-words property.

The property will have two main use cases:
 - Checking host capabilities, by checking the features of the host
   CPU model
 - Checking which features are enabled on each CPU model

Example output:

  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=feature-words
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 101
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 563346425
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 0
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 2155880449
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 126614521

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
Changes v11 - v12:
 * Remove unnecessary entries from .gitignore
 * Fix indentation of x86_cpu_get_feature_words() declaration
 * Rebase on top of qom-cpu-next
   (commit bd87d2a - target-i386: Use FeatureWord loop on 
filter_features_for_kvm())

Changes v1 - v2 (series marked as v11):
 * Merge the non-qapi and qapi patches, to keep series simpler
 * Use the feature word array series as base, so we don't have
   to set the feature word values one-by-one in the code
 * Change type name of property from x86-cpu-feature-words to
   X86CPUFeatureWordInfo
 * Remove cpu-qapi-schema.json and simply add the type definitions
   to qapi-schema.json, to keep the changes simpler
   * This required compiling qapi-types.o and qapi-visit.o into
 *-user as well
---
 Makefile.objs |  7 +-
 qapi-schema.json  | 32 +
 target-i386/cpu.c | 70 +--
 3 files changed, 96 insertions(+), 13 deletions(-)

diff --git a/Makefile.objs b/Makefile.objs
index fcb303a..286ce06 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -79,10 +79,15 @@ common-obj-$(CONFIG_SMARTCARD_NSS) += $(libcacard-y)
 ##
 # qapi
 
-common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o
+common-obj-y += qmp-marshal.o
 common-obj-y += qmp.o hmp.o
 endif
 
+##
+# some qapi visitors are used by both system and user emulation:
+
+common-obj-y += qapi-visit.o qapi-types.o
+
 ###
 # Target-independent parts used in system and user emulation
 common-obj-y += qemu-log.o
diff --git a/qapi-schema.json b/qapi-schema.json
index 7797400..199744a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3587,3 +3587,35 @@
 ##
 {'command': 'query-command-line-options', 'data': { '*option': 'str' },
  'returns': ['CommandLineOptionInfo'] }
+
+##
+# @X86CPURegister32
+#
+# A X86 32-bit register
+#
+# Since: 1.5
+##
+{ 'enum': 'X86CPURegister32',
+  'data': [ 'EAX', 'EBX', 'ECX', 'EDX', 'ESP', 'EBP', 'ESI', 'EDI' ] }
+
+##
+# @X86CPUFeatureWordInfo
+#
+# Information about a X86 CPU feature word
+#
+# @cpuid-input-eax: Input EAX value for CPUID instruction for that feature word
+#
+# @cpuid-input-ecx: #optional Input ECX value for CPUID instruction for that
+#   feature word
+#
+# @cpuid-register: Output register containing the feature bits
+#
+# @features: value of output register, containing the feature bits
+#
+# Since: 1.5
+##
+{ 'type': 'X86CPUFeatureWordInfo',
+  'data': { 'cpuid-input-eax': 'int',
+'*cpuid-input-ecx': 'int',
+'cpuid-register': 'X86CPURegister32',
+'features': 'int' } }
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index a39b364..3857514 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -30,6 +30,8 @@
 #include qemu/config-file.h
 #include qapi/qmp/qerror.h
 
+#include qapi-types.h
+#include qapi-visit.h
 #include qapi/visitor.h
 #include sysemu/arch_init.h
 
@@ -195,23 +197,34 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 },
 };
 
+typedef struct X86RegisterInfo32 {
+/* Name of register */
+const char *name;
+/* QAPI enum value register */
+X86CPURegister32 qapi_enum;
+} X86RegisterInfo32;
+
+#define REGISTER(reg) \
+[R_##reg] = { .name = #reg, .qapi_enum = X86_C_P_U_REGISTER32_##reg }
+X86RegisterInfo32 x86_reg_info_32[CPU_NB_REGS32] = {
+REGISTER(EAX),
+REGISTER(ECX),
+REGISTER(EDX),
+REGISTER

[libvirt] [PATCH qom-cpu-next 3/3] target-i386: Add filtered-features property to X86CPU

[Eduardo Habkost]

This property will contain all the features that were removed from the
CPU because they are not supported by the host.

This way, libvirt or other management tools can emulate the
check/enforce behavior by checking if filtered-properties is all zeroes,
before starting the guest.

Example output where some features were missing:

  $ ./install/bin/qemu-system-x86_64 -enable-kvm -cpu Haswell,check -S -qmp 
unix:/tmp/m,server,nowait
  warning: host doesn't support requested feature: CPUID.01H:ECX.fma [bit 12]
  warning: host doesn't support requested feature: CPUID.01H:ECX.movbe [bit 22]
  warning: host doesn't support requested feature: CPUID.01H:ECX.tsc-deadline 
[bit 24]
  warning: host doesn't support requested feature: CPUID.01H:ECX.xsave [bit 26]
  warning: host doesn't support requested feature: CPUID.01H:ECX.avx [bit 28]
  warning: host doesn't support requested feature: CPUID.07H:EBX.fsgsbase [bit 
0]
  warning: host doesn't support requested feature: CPUID.07H:EBX.bmi1 [bit 3]
  warning: host doesn't support requested feature: CPUID.07H:EBX.hle [bit 4]
  warning: host doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5]
  warning: host doesn't support requested feature: CPUID.07H:EBX.smep [bit 7]
  warning: host doesn't support requested feature: CPUID.07H:EBX.bmi2 [bit 8]
  warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9]
  warning: host doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 
10]
  warning: host doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11]
  [...]
  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1] 
--property=filtered-features
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 0
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 0
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 4025
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 356519936
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 0

Example output when no feature is missing:

  $ ./install/bin/qemu-system-x86_64 -enable-kvm -cpu Nehalem,enforce -S -qmp 
unix:/tmp/m,server,nowait
  [...]
  $ ./QMP/qmp --path=/tmp/m qom-get --path=/machine/unattached/device[1]
  --property=filtered-features
  item[0].cpuid-register: EDX
  item[0].cpuid-input-eax: 2147483658
  item[0].features: 0
  item[1].cpuid-register: EAX
  item[1].cpuid-input-eax: 1073741825
  item[1].features: 0
  item[2].cpuid-register: EDX
  item[2].cpuid-input-eax: 3221225473
  item[2].features: 0
  item[3].cpuid-register: ECX
  item[3].cpuid-input-eax: 2147483649
  item[3].features: 0
  item[4].cpuid-register: EDX
  item[4].cpuid-input-eax: 2147483649
  item[4].features: 0
  item[5].cpuid-register: EBX
  item[5].cpuid-input-eax: 7
  item[5].features: 0
  item[5].cpuid-input-ecx: 0
  item[6].cpuid-register: ECX
  item[6].cpuid-input-eax: 1
  item[6].features: 0
  item[7].cpuid-register: EDX
  item[7].cpuid-input-eax: 1
  item[7].features: 0

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
Changes v11 - v12:
 * Rebase on top of qom-cpu-next
   (commit bd87d2a - target-i386: Use FeatureWord loop on 
filter_features_for_kvm())
---
 target-i386/cpu.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 38793bc..eb1825b 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1418,11 +1418,11 @@ static void x86_cpuid_set_apic_id(Object *obj, Visitor 
*v, void *opaque,
 cpu-env.cpuid_apic_id = value;
 }
 
+/* Generic getter for feature-words and filtered-features properties */
 static void x86_cpu_get_feature_words(Object *obj, Visitor *v, void *opaque,
   const char *name, Error **errp)
 {
-X86CPU *cpu = X86_CPU(obj);
-CPUX86State *env = cpu-env;
+uint32_t *array = (uint32_t *)opaque;
 FeatureWord w;
 Error *err = NULL;
 X86CPUFeatureWordInfo word_infos[FEATURE_WORDS] = { };
@@ -1436,7 +1436,7 @@ static void x86_cpu_get_feature_words(Object *obj, 
Visitor *v, void *opaque,
 qwi-has_cpuid_input_ecx = wi-cpuid_needs_ecx;
 qwi-cpuid_input_ecx = wi-cpuid_ecx;
 qwi-cpuid_register = x86_reg_info_32[wi-cpuid_reg].qapi_enum;
-qwi-features = env-features[w];
+qwi-features = array[w];
 
 /* List will be in reverse order, but order shouldn't matter */
 list_entries[w].next = list;
@@ -2444,7 +2444,10 @@ static void x86_cpu_initfn(Object *obj)
 x86_cpuid_set_apic_id, NULL, NULL, NULL

[libvirt] [PATCH qom-cpu-next 0/3] X86CPU: feature-words/filtered-features properties (v12)

[Eduardo Habkost]

Resubmitting after a rebase and a few trivial changes.

Changes v11 - v12:
 * Remove unnecessary entries from .gitignore
 * Fix indentation of x86_cpu_get_feature_words() declaration
 * Rebase on top of qom-cpu-next
   (commit bd87d2a - target-i386: Use FeatureWord loop on 
filter_features_for_kvm())

Git tree for reference:

git://github.com/ehabkost/qemu-hacks.git work/cpu-raw-features.v12

Eduardo Habkost (3):
  target-i386: Add feature-words property
  target-i386: Introduce X86CPU.filtered_features field
  target-i386: Add filtered-features property to X86CPU

 Makefile.objs |  7 -
 qapi-schema.json  | 32 
 target-i386/cpu-qom.h |  3 ++
 target-i386/cpu.c | 82 +--
 4 files changed, 108 insertions(+), 16 deletions(-)

-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH qom-cpu-next 2/3] target-i386: Introduce X86CPU.filtered_features field

[Eduardo Habkost]

This field will contain the feature bits that were filtered out because
of missing host support.

Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
Changes v11 - v12:
 * Rebase on top of qom-cpu-next
   (commit bd87d2a - target-i386: Use FeatureWord loop on 
filter_features_for_kvm())
---
 target-i386/cpu-qom.h | 3 +++
 target-i386/cpu.c | 9 ++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index f890f1c..849cedf 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -65,6 +65,9 @@ typedef struct X86CPU {
 /* public */
 
 CPUX86State env;
+
+/* Features that were filtered out because of missing host capabilities */
+uint32_t filtered_features[FEATURE_WORDS];
 } X86CPU;
 
 static inline X86CPU *x86_env_get_cpu(CPUX86State *env)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 3857514..38793bc 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1698,9 +1698,12 @@ static void filter_features_for_kvm(X86CPU *cpu)
 
 for (w = 0; w  FEATURE_WORDS; w++) {
 FeatureWordInfo *wi = feature_word_info[w];
-env-features[w] = kvm_arch_get_supported_cpuid(s, wi-cpuid_eax,
-wi-cpuid_ecx,
-wi-cpuid_reg);
+uint32_t host_feat = kvm_arch_get_supported_cpuid(s, wi-cpuid_eax,
+ wi-cpuid_ecx,
+ wi-cpuid_reg);
+uint32_t requested_features = env-features[w];
+env-features[w] = host_feat;
+cpu-filtered_features[w] = requested_features  ~env-features[w];
 }
 }
 #endif
-- 
1.8.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] target-i386: Disable CPUID_EXT_MONITOR when KVM is enabled

[Eduardo Habkost]

(CCing libvirt people)

On Tue, May 28, 2013 at 06:48:52PM +0200, Andreas Färber wrote:
 Am 28.05.2013 18:46, schrieb Paolo Bonzini:
  Il 28/05/2013 18:34, Bandan Das ha scritto:
  Eduardo Habkost ehabk...@redhat.com writes:
 
  On Mon, May 27, 2013 at 02:21:36PM +0200, Paolo Bonzini wrote:
  Il 27/05/2013 14:09, Eduardo Habkost ha scritto:
  On Sat, May 25, 2013 at 08:25:49AM +0200, Paolo Bonzini wrote:
  Il 25/05/2013 03:21, Bandan Das ha scritto:
  There is one user-visible effect: -cpu ...,enforce will stop failing
  because of missing KVM support for CPUID_EXT_MONITOR. But that's 
  exactly
  the point: there's no point in having CPU model definitions that would
  never work as-is with neither TCG or KVM. This patch is changing the
  meaning of (e.g.) -machine ...,accel=kvm -cpu Opteron_G3 to match 
  what
  was already happening in practice.
 
  But then -cpu Opteron_G3 does not match a real Opteron G3.  Is it
  worth it?
 
  No models match a real CPU this way, because neither TCG or KVM
  support all features supported by a real CPU. I ask the opposite
  question: is it worth maintaining an accurate CPU model definition
  that would never work without feature-bit tweaking in the command-line?
 
  It would work with TCG.  Changing TCG to KVM should not change hardware
  if you use -cpu ...,enforce, so it is right that it fails when
  starting with KVM.
 
 
  Changing between KVM and TCG _does_ change hardware, today (with or
  without check/enforce). All CPU models on TCG have features not
  supported by TCG automatically removed. See the if (!kvm_enabled())
  block at x86_cpu_realizefn().
 
  Yes, this is exactly why I was inclined to remove the monitor flag. 
  We already have uses of kvm_enabled() to set (or remove) kvm specific 
  stuff,
  and this change is no different.
  
  Do any of these affect something that is part of x86_def_t?
 
 The vendor comes to mind.

I believe we can still consider the vendor field a special one: if
other components care about the TCG/KVM difference regarding the
vendor field, they can simply set vendor explicitly on the
command-line.

  I can see Paolo's point though, having 
  a common definition probably makes sense too.
  

Paolo is convincing me that keeping the rest of the features exactly the
same on TCG and KVM modes (and making check/enforce work for TCG as
well) would simplify the logic a lot. This will add a little extra work
for libvirt, that will probably need to use -cpu Opteron_G3,-monitor
once it implements enforce-mode (to make sure the results really match
existing libvirt assumptions about the Opteron_G* models), but it is
probably worth it.

I will give it a try and send a proposal soon.


  (That's why I argue that we need separate classes/names for TCG and KVM
  modes. Otherwise our predefined models get less useful as they will
  require low-level feature-bit fiddling on the libvirt side to make them
  work as expected.)
 
  Agreed. From a user's perspective, I think the more a CPU model just 
  works,
  whether it's KVM or TCG, the better.
  
  Yes, that's right.  But I think extending the same expectation to -cpu
  ...,enforce is not necessary, and perhaps even wrong for -cpu
  ...,check since it's only a warning rather than a fatal error.
  
  Paolo
  
 
 
 -- 
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Eduardo Habkost]

On Mon, Jul 22, 2013 at 07:24:24PM +0800, Peter Huang(Peng) wrote:
 Hi, Everyone
 
 I have been encountered a problem recently.
 My box uses Nehalem E5520 CPU, and this model doesn't support x2apic feature.
 I created a VM on KVM, and uses cpu mode=pass-through, I can get the right cpu
 model from the VM, but I can also see that the CPU in the vm supports x2apic.
 
 This seems werid.
 From QEMU's CPU model definition, Nehalem also doesn't support x2apic.
 
 Can anyone explain it?
 

libvirt's host-passthrough uses -cpu host', and it -cpu host
enables every feature that can be enabled on the host. As KVM x2apic
emulation doesn't require host CPU support, it gets enabled.

If the behavior of -cpu host doesn't match libvirt expectations, we
need to clarify what are the requirements, and maybe have a try to be
close to host CPU mode as opposed to the current enable everything
that can be enabled mode.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 6/7] qemu: Probe QEMU binary for host CPU

[Eduardo Habkost]

On Tue, Jul 23, 2013 at 05:19:03PM +0100, Daniel P. Berrange wrote:
 On Tue, Jul 23, 2013 at 06:11:35PM +0200, Jiri Denemark wrote:
  Since QEMU and kvm may filter some host CPU features or add efficiently
  emulated features, asking QEMU binary for host CPU data provides
  better results when we later use the data for building guest CPUs.
  ---
   src/qemu/qemu_capabilities.c | 44 
  +++-
   src/qemu/qemu_capabilities.h |  2 ++
   2 files changed, 45 insertions(+), 1 deletion(-)
  
  diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
  index 9440396..d46a059 100644
  --- a/src/qemu/qemu_capabilities.c
  +++ b/src/qemu/qemu_capabilities.c
  @@ -253,6 +253,7 @@ struct _virQEMUCaps {
   
   size_t ncpuDefinitions;
   char **cpuDefinitions;
  +virCPUDefPtr hostCPU;
   
   size_t nmachineTypes;
   char **machineTypes;
  @@ -1757,6 +1758,9 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr 
  qemuCaps)
   goto error;
   }
   
  +if (!(ret-hostCPU = virCPUDefCopy(qemuCaps-hostCPU)))
  +goto error;
  +
   if (VIR_ALLOC_N(ret-machineTypes, qemuCaps-nmachineTypes)  0)
   goto error;
   if (VIR_ALLOC_N(ret-machineAliases, qemuCaps-nmachineTypes)  0)
  @@ -1796,6 +1800,7 @@ void virQEMUCapsDispose(void *obj)
   VIR_FREE(qemuCaps-cpuDefinitions[i]);
   }
   VIR_FREE(qemuCaps-cpuDefinitions);
  +virCPUDefFree(qemuCaps-hostCPU);
   
   virBitmapFree(qemuCaps-flags);
   
  @@ -2485,7 +2490,6 @@ virQEMUCapsInitQMPCommandNew(const char *binary,
  -no-user-config,
  -nodefaults,
  -nographic,
  -   -M, none,
  -qmp, monitor,
  -pidfile, pidfile,
  -daemonize,
  @@ -2617,6 +2621,7 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
   
   cmd = virQEMUCapsInitQMPCommandNew(qemuCaps-binary, monarg, pidfile,
  runUid, runGid);
  +virCommandAddArgList(cmd, -M, none, NULL);
   
   if ((ret = virQEMUCapsInitQMPCommandRun(cmd, qemuCaps-binary, pidfile,
   config, mon, pid))  0) {
  @@ -2679,6 +2684,37 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
   if (virQEMUCapsProbeQMPCommandLine(qemuCaps, mon)  0)
   goto cleanup;
   
  +if ((qemuCaps-arch == VIR_ARCH_I686 ||
  + qemuCaps-arch == VIR_ARCH_X86_64) 
  +(virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM) ||
  + virQEMUCapsGet(qemuCaps, QEMU_CAPS_ENABLE_KVM)) 
  +virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_HOST) 
  +qemuCaps-nmachineTypes) {
  +virQEMUCapsInitQMPCommandAbort(cmd, mon, pid, pidfile);
  +
  +VIR_DEBUG(Checking host CPU data provided by %s, 
  qemuCaps-binary);
  +cmd = virQEMUCapsInitQMPCommandNew(qemuCaps-binary, monarg, 
  pidfile,
  +   runUid, runGid);
  +virCommandAddArgList(cmd, -cpu, host, NULL);
  +/* -cpu host gives the same CPU for all machine types so we just
  + * use the first one when probing
  + */
  +virCommandAddArg(cmd, -machine);
  +virCommandAddArgFormat(cmd, %s,accel=kvm,
  +   qemuCaps-machineTypes[0]);
  +
  +if (virQEMUCapsInitQMPCommandRun(cmd, qemuCaps-binary, pidfile,
  + config, mon, pid)  0)
  +goto cleanup;
  +
  +qemuCaps-hostCPU = qemuMonitorGetCPU(mon, qemuCaps-arch);
  +if (qemuCaps-hostCPU) {
  +char *cpu = virCPUDefFormat(qemuCaps-hostCPU, 0);
  +VIR_DEBUG(Host CPU reported by %s: %s, qemuCaps-binary, 
  cpu);
  +VIR_FREE(cpu);
  +}
  +}
 
 
 This code is causing us to invoke the QEMU binary multiple times,
 which is something we worked really hard to get away from. I really,
 really don't like this as an approach. QEMU needs to be able to
 give us the data we need here without multiple invocations.
 
 eg, by allowing the monitor command to specify 'kvm' vs 'qemu'
 when asking for data, so you can interrogate it without having
 to re-launch it with different accel=XXX args.

The specific information libvirt requires here depend on KVM being
initialized, and QEMU code/interfaces currently assume that: 1) there's
only 1 machine being initialized, and it is initialized very early; 2)
there's only one accelerator being initialized, and it is initialized
very early.

I have no idea how long it will take for QEMU to provide a QMP interface
for late/multiple initialization of machines/accelerators. In the
meantime, the way libvirt queries for host CPU capabilities without
taking QEMU and kernel capabilities into account is a serious bug we
need to solve.

Maybe if we are lucky we can 

Re: [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU

[Eduardo Habkost]

On Tue, Jul 23, 2013 at 07:32:46PM +0200, Jiri Denemark wrote:
 On Tue, Jul 23, 2013 at 19:28:38 +0200, Jiri Denemark wrote:
  On Tue, Jul 23, 2013 at 17:32:42 +0100, Daniel Berrange wrote:
   On Tue, Jul 23, 2013 at 06:11:33PM +0200, Jiri Denemark wrote:
---
 src/qemu/qemu_monitor.c|  21 +++
 src/qemu/qemu_monitor.h|   3 +
 src/qemu/qemu_monitor_json.c   | 162 
+
 src/qemu/qemu_monitor_json.h   |   6 +
 tests/Makefile.am  |   1 +
 .../qemumonitorjson-getcpu-empty.data  |   2 +
 .../qemumonitorjson-getcpu-empty.json  |  46 ++
 .../qemumonitorjson-getcpu-filtered.data   |   4 +
 .../qemumonitorjson-getcpu-filtered.json   |  46 ++
 .../qemumonitorjson-getcpu-full.data   |   4 +
 .../qemumonitorjson-getcpu-full.json   |  46 ++
 .../qemumonitorjson-getcpu-host.data   |   5 +
 .../qemumonitorjson-getcpu-host.json   |  45 ++
 tests/qemumonitorjsontest.c|  74 ++
 14 files changed, 465 insertions(+)
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.data
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.json
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.data
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.json
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.data
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.json
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.data
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.json
   
   ACK, though I believe the design of this monitor API is flawed
   because it requires you to re-launch QEMU with different accel
   args
  
  Not really, this can be used in tcg too. It's just when we want to get
  the data for host CPU, we need to enable kvm as tcg knows nothing
  about that CPU. Which makes sense as kvm (the kernel module) influences
  how the host CPU will look like.
 
 However, you need to have a CPU to be able to ask for his properties
 (which kinda makes sense too) and for that you also need a machine with
 type != none. Which makes sense too, as the CPU may differ depending on
 machine type (which, however, does not happen for host CPU).

In addition to the -cpu host KVM initialization problem, this is an
additional problem with the current interfaces provided by QEMU:

1) libvirt needs to query data that depend on chosen machine-type and
   CPU model
2) Some machine-type behavior is code and not introspectable data
   * Luckily most of the data we need in this case should/will be
 encoded in the compat_props tables.
   * In either case, we don't have an API to query for machine-type
 compat_props information yet.
3) CPU model behavior will be modelled as CPU class behavior. Like
   on the machine-type case, some of the CPU-model-specific behavior may
   be modelled as code, and not introspectable data.
   * However, e may be able to eventually encode most or all of
 CPU-model-specific behavior simply as different per-CPU-class
 property defaults.
   * In either case, we don't have an API for QOM class introspection,
 yet.

But there's something important in this case: the resulting CPUID data
for a specific machine-type + CPU-model combination must be always the
same, forever. This means libvirt may even use a static table, or cache
this information indefinitely.

(Note that I am not talking about -cpu host, here, but about all the
other CPU models)

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU

[Eduardo Habkost]

On Wed, Jul 24, 2013 at 11:03:03AM +0100, Daniel P. Berrange wrote:
 On Tue, Jul 23, 2013 at 07:28:38PM +0200, Jiri Denemark wrote:
  On Tue, Jul 23, 2013 at 17:32:42 +0100, Daniel Berrange wrote:
   On Tue, Jul 23, 2013 at 06:11:33PM +0200, Jiri Denemark wrote:
---
 src/qemu/qemu_monitor.c|  21 +++
 src/qemu/qemu_monitor.h|   3 +
 src/qemu/qemu_monitor_json.c   | 162 
+
 src/qemu/qemu_monitor_json.h   |   6 +
 tests/Makefile.am  |   1 +
 .../qemumonitorjson-getcpu-empty.data  |   2 +
 .../qemumonitorjson-getcpu-empty.json  |  46 ++
 .../qemumonitorjson-getcpu-filtered.data   |   4 +
 .../qemumonitorjson-getcpu-filtered.json   |  46 ++
 .../qemumonitorjson-getcpu-full.data   |   4 +
 .../qemumonitorjson-getcpu-full.json   |  46 ++
 .../qemumonitorjson-getcpu-host.data   |   5 +
 .../qemumonitorjson-getcpu-host.json   |  45 ++
 tests/qemumonitorjsontest.c|  74 ++
 14 files changed, 465 insertions(+)
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.data
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.json
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.data
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.json
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.data
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.json
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.data
 create mode 100644 
tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.json
   
   ACK, though I believe the design of this monitor API is flawed
   because it requires you to re-launch QEMU with different accel
   args
  
  Not really, this can be used in tcg too. It's just when we want to get
  the data for host CPU, we need to enable kvm as tcg knows nothing
  about that CPU. Which makes sense as kvm (the kernel module) influences
  how the host CPU will look like.
 
 Is there no ioctl() for the KVM module we can just invoke directly to
 discover what CPU flag filtering it will perform. Presumably QEMU is
 using some ioctl to discover this, so libvirt ought to be able to
 too.
 

Yes, there is: GET_SUPPORTED_CPUID. But availability of some features
may depend on QEMU capabilities as well. On those cases libvirt may need
to combine the GET_SUPPORTED_CPUID results with what it knows about QEMU
capabilities. But this should work as long as we report and document
QEMU capabilities/options that affect CPU features very clearly.

That may be an appropriate way to go to, if you don't mind having
low-level KVM ioctl() code inside libvirt, that duplicates some QEMU
logic.

(But we still have the problem of querying/reporting CPU feature details
that depend on machine-type+CPU-model [that is not addressed by this
series yet]. See my previous message about it)

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU

[Eduardo Habkost]

On Thu, Jul 25, 2013 at 10:45:10AM +0100, Daniel P. Berrange wrote:
 On Wed, Jul 24, 2013 at 03:25:19PM -0300, Eduardo Habkost wrote:
  On Tue, Jul 23, 2013 at 07:32:46PM +0200, Jiri Denemark wrote:
   On Tue, Jul 23, 2013 at 19:28:38 +0200, Jiri Denemark wrote:
On Tue, Jul 23, 2013 at 17:32:42 +0100, Daniel Berrange wrote:
 On Tue, Jul 23, 2013 at 06:11:33PM +0200, Jiri Denemark wrote:
  ---
   src/qemu/qemu_monitor.c|  21 +++
   src/qemu/qemu_monitor.h|   3 +
   src/qemu/qemu_monitor_json.c   | 162 
  +
   src/qemu/qemu_monitor_json.h   |   6 +
   tests/Makefile.am  |   1 +
   .../qemumonitorjson-getcpu-empty.data  |   2 +
   .../qemumonitorjson-getcpu-empty.json  |  46 ++
   .../qemumonitorjson-getcpu-filtered.data   |   4 +
   .../qemumonitorjson-getcpu-filtered.json   |  46 ++
   .../qemumonitorjson-getcpu-full.data   |   4 +
   .../qemumonitorjson-getcpu-full.json   |  46 ++
   .../qemumonitorjson-getcpu-host.data   |   5 +
   .../qemumonitorjson-getcpu-host.json   |  45 ++
   tests/qemumonitorjsontest.c|  74 ++
   14 files changed, 465 insertions(+)
   create mode 100644 
  tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.data
   create mode 100644 
  tests/qemumonitorjsondata/qemumonitorjson-getcpu-empty.json
   create mode 100644 
  tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.data
   create mode 100644 
  tests/qemumonitorjsondata/qemumonitorjson-getcpu-filtered.json
   create mode 100644 
  tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.data
   create mode 100644 
  tests/qemumonitorjsondata/qemumonitorjson-getcpu-full.json
   create mode 100644 
  tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.data
   create mode 100644 
  tests/qemumonitorjsondata/qemumonitorjson-getcpu-host.json
 
 ACK, though I believe the design of this monitor API is flawed
 because it requires you to re-launch QEMU with different accel
 args

Not really, this can be used in tcg too. It's just when we want to get
the data for host CPU, we need to enable kvm as tcg knows nothing
about that CPU. Which makes sense as kvm (the kernel module) influences
how the host CPU will look like.
   
   However, you need to have a CPU to be able to ask for his properties
   (which kinda makes sense too) and for that you also need a machine with
   type != none. Which makes sense too, as the CPU may differ depending on
   machine type (which, however, does not happen for host CPU).
  
  In addition to the -cpu host KVM initialization problem, this is an
  additional problem with the current interfaces provided by QEMU:
  
  1) libvirt needs to query data that depend on chosen machine-type and
 CPU model
  2) Some machine-type behavior is code and not introspectable data
 * Luckily most of the data we need in this case should/will be
   encoded in the compat_props tables.
 * In either case, we don't have an API to query for machine-type
   compat_props information yet.
  3) CPU model behavior will be modelled as CPU class behavior. Like
 on the machine-type case, some of the CPU-model-specific behavior may
 be modelled as code, and not introspectable data.
 * However, e may be able to eventually encode most or all of
   CPU-model-specific behavior simply as different per-CPU-class
   property defaults.
 * In either case, we don't have an API for QOM class introspection,
   yet.
  
  But there's something important in this case: the resulting CPUID data
  for a specific machine-type + CPU-model combination must be always the
  same, forever. This means libvirt may even use a static table, or cache
  this information indefinitely.
  
  (Note that I am not talking about -cpu host, here, but about all the
  other CPU models)
 
 Hmm, so if the CPU filtering can vary per every single individual
 machine type, then the approach Jiri started here, of invoking QEMU
 with machine type set to query the CPU after it was created, is
 definitely not something we can follow. It is just far too inefficient.

I believe there's some confusion here: we are trying to solve two
problems:

1) CPU feature filtering (checking which features are available in a
   given host)
2) CPU model probing (checking what exactly is going to be available
   when a given CPU model is used, in case nothing is filtered out)


Item (1) depends on: host CPU capabilities, host kernel capabilities,
QEMU capabilities, presence of some few QEMU command-line options (e.g.
kernel irqchip), but shouldn't depend on the machine-type. It depends on
/dev/kvm