Re: [pve-devel] [PATCH-SERIES v3 qemu-server/manager/common] add and set x86-64-v2 as default model for new vms and detect best cpumodel

["DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>]

> 
> Note that migration between CPUs of different vendors is not a
> supported
> use case (it will always depend on specific models, kernel versions,
> etc.), so we can only justify not adding it to the new default model
> if
> it doesn't make life worse for everybody else.
> 
> And I'd be a bit careful to jump to general conclusions just from one
> forum post.
> 
> It seems like you were the one adding the flag ;)
> 
> 
yes, I known ^_^   (It's the default too on rhev, but they are not
supporting amd-intel migration too).



> and the LWN-archived mail linked in the commit message says
> 
> > Ticket locks have an inherent problem in a virtualized case,
> > because
> > the vCPUs are scheduled rather than running concurrently (ignoring
> > gang scheduled vCPUs).  This can result in catastrophic performance
> > collapses when the vCPU scheduler doesn't schedule the correct
> > "next"
> > vCPU, and ends up scheduling a vCPU which burns its entire
> > timeslice
> > spinning.  (Note that this is not the same problem as lock-holder
> > preemption, which this series also addresses; that's also a
> > problem,
> > but not catastrophic).
> 
> "catastrophic performance collapses" doesn't sound very promising :/
> 

I have found another thread here:
https://lore.kernel.org/all/0484ea3f-4ba7-4b93-e976-098c5717166e@redhat.com/
where paolo have done benchmark with only 3% difference.
but yes, still slower anyway.

at minimum, it could be interesting to expose the flag in the gui, for
users really needed intel-amd migration.



> But if we find that
> kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+sep,+lahf_lm,+popcnt,+sse4.
> 1,+sse4.2,+ssse3
> causes issues (even if not cross-vendor live-migrating) with the
> +kvm_pv_unhalt flag, but not without, it would be a much more
> convincing
> reason against adding the flag for the new default.
> 
ok ! (I will send a new patch version today)