qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models
Date: Wed, 24 Jun 2015 12:58:23 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Jun 24, 2015 at 04:38:51PM +0200, Paolo Bonzini wrote:
[...]
> 1) libvirt should _not_ change the flags that the user passes via XML
> just because it thinks that QEMU has those flags.  This makes it
> possible for libvirt to keep cpu_map.xml up-to-date without worrying
> about versioning.

That's true, and it would solve cases like people asking libvirt for
"Haswell without rdand" and getting QEMU running "-cpu Haswell" (which
has rdrand enabled) because libvirt thinks Haswell doesn't have rdrand.

> 
> 2) libvirt should not add/remove flags when the user specifies
> host-model (i.e. -cpu SandyBridge, not -cpu
> SandyBridge,+f16c,+rdrand,+erms,+whatever).  host-model has had so many
> bugs reported for it that I hope this could be done unconditionally even
> if it is not backwards-compatible.  Or perhaps introduce a new name and
> deprecate host-model.  I don't know.

In other words, libvirt should not assume anything about the QEMU-side
CPU models. If the user asks for "Broadwell", it should use "-cpu
Broadwell", if the user asks for "Broadwell + fpu", it should use "-cpu
Broadwell,+fpu" even if it believes every CPU model since 486 has FPU
enabled.

The reason for that is that we may still introduce CPU model changes, as
long as they are not going to mean new host-side dependencies (see
commit 78a611f1936b3eac8ed78a2be2146a742a85212c for an example, where we
added f16c and rdand to Haswell and Broadwell).

> 
> 3) regarding "enforce", there are indeed some cases where it would break:
> 
> - Haswell/Broadwell CPU model after TSX removal
> 
> - qemu64 with KVM
> 
> - pretty much everything including qemu64 with TCG

- Everything involving KVM CPUID features, that change depending on the
  kernel version.

- Intel CPU models that had VMX enabled in older machine-types,
  and may or may not have VMX enabled depending on kernel VMX nesting
  configuration.

> 
> So libvirt here could allow _now_ the user to specify enforce, either
> via XML or via qemu.conf (or via XML + a default specified via qemu.conf).

More precisely, libvirt would emulate "enforce" mode by checking the
"filtered-features", because "enforce" error messages are not
machine-friendly.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]