qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: xtec@trimaso.com.mx
Cc: qemu-devel@nongnu.org
Subject: Re: Qemu setting "-cpu host" seems broken with Windows vms
Date: Fri, 12 Jan 2024 18:32:47 +0000	[thread overview]
Message-ID: <ZaGFz7DcDR0ZWH_f@redhat.com> (raw)
In-Reply-To: <8cceee40e32dab3e1913e50c221475ea@trimaso.com.mx>

On Thu, Dec 28, 2023 at 11:45:18AM -0600, xtec@trimaso.com.mx wrote:
> I noticed something weird when using "-cpu host" with Windows vms.
> First, I always use it along with ",hv_passthrough" as well.
> 
> First, performance: since some years ago, since prior to qemu 6.2 until
> latest 8.2, win10 and win11 vms always worked slower than expected. This
> could be noticed by comparing booting/starting times between vm and a bare
> metal installation, but I particularly measured it when installing windows
> cumulative updates through windows update. On vm, from downloading to
> finishing rebooting it always took 1.5 circa 1.5 hours, while just 40
> minutes on bare metal.
> 
> Second, and more recently, newer windows 11 23h2 seems to have big problem
> with "-cpu host".
> When trying to update from 22h2 to 23h2 I got either black screen or bsod
> after trying to reboot.
> Also, same result when trying to install 23h2 from scratch.
> This on qemu 7.1 and 8.2.
> Did a long search, and finally found the cause which also solved the problem
> for me:
> https://forum.proxmox.com/threads/new-windows-11-vm-fails-boot-after-update.137543/
> I found similar problems and similar solution in other forums as well.
> 
> So in my case, physical host cpu is intel core 11th gen; tried using
> libvirt's "virsh capabilities" to see which qemu cpu model better matched,
> and for some reason it gave Broadwell instead of newer Skylake...

Intel has many different variants of each named CPU generation, and
QEMU's CPU model only reflects one particular variant.  So it is
possible that you have a Skylake variant that lacks 1 feature flag
that QEMU's Skylake model has. This in turn causes libvirt to find
the next best named model with all flags available and in your case
libvirt decided Broadwell was best.

> Anyway, tried with "-cpu <Broadwell_model>,hv_passthrough", and this solved
> *both* problems: performance finally matched bare metal in all aspects, and
> the windows 23h2 problem was finally gone.
> 
> On IRC, it was suggested to try "-cpu host" and "disabling CPU bits" one by
> one until finding the culprit. But I don't know how to do this...

So you need to figure out which bits are different between 'Broadwell' and
'host' for your machine.

Assuming you have qemu.git checked out, you want to run

   ./scripts/qmp/qmp-shell-wrap -p  /usr/bin/qemu-system-x86_64 -display none -accel kvm

in the QMP shell now run

   query-cpu-model-expansion type=full model={'name':'Broadwell'}

and save the list of features it reports. then run

   query-cpu-model-expansion type=full model={'name':'host'}

and save the list of features it reports too.

Now diff the two feature lists.

If the diff shows that 'sse4a' was missing in Broadwell but present in
host, then try

   -cpu Broadwell,hv_passthrough,sse4a

keep appending more features on -cpu, and if you're lucky you might
hit one that triggers the problem.

Not every difference though can be controlled via -cpu flags, so it is
posible there's something inherantly different about the 'host' model
that triggers this problem.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



      parent reply	other threads:[~2024-01-12 18:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-28 17:45 Qemu setting "-cpu host" seems broken with Windows vms xtec
2023-12-29 13:10 ` Stefan Hajnoczi
2024-01-16 17:56   ` Paolo Bonzini
2024-01-19  0:13     ` xtec
2024-01-12 18:32 ` Daniel P. Berrangé [this message]

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=ZaGFz7DcDR0ZWH_f@redhat.com \
    --to=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=xtec@trimaso.com.mx \
    /path/to/YOUR_REPLY

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

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