On Thu, Dec 28, 2023 at 11:45:18AM -0600, x...@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 :|
