[pve-devel] cpuflag: pcid needed in guest for good performance after meltdown

[Fabian Grünbichler]

On Tue, Jan 09, 2018 at 08:47:10PM +0100, Stefan Priebe - Profihost AG wrote:
> Am 09.01.2018 um 19:25 schrieb Fabian Grünbichler:
> > On Tue, Jan 09, 2018 at 04:31:40PM +0100, Stefan Priebe - Profihost AG wrote:
> >>
> >> Am 09.01.2018 um 16:18 schrieb Fabian Grünbichler:
> >>> On Tue, Jan 09, 2018 at 02:58:24PM +0100, Fabian Grünbichler wrote:
> >>>> On Mon, Jan 08, 2018 at 09:34:57PM +0100, Stefan Priebe - Profihost AG wrote:
> >>>>> Hello,
> >>>>>
> >>>>> for meltdown mitigation and performance it's important to have the pcid
> >>>>> flag passed down to the guest (f.e.
> >>>>> https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU).
> >>>>>
> >>>>> My host shows the flag:
> >>>>> # grep ' pcid ' /proc/cpuinfo  | wc -l
> >>>>> 56
> >>>>>
> >>>>> But the guest does not:
> >>>>> # grep pcid /proc/cpuinfo
> >>>>> #
> >>>>>
> >>>>> Guest was started with:
> >>>>> -cpu IvyBridge,+kvm_pv_unhalt,+kvm_pv_eoi,enforce,vendor=GenuineIntel
> >>>>>
> >>>>> Is this something missing in host kernel or in PVE?
> >>>>>
> >>>>> Greets,
> >>>>> Stefan
> >>>>
> >>>> we are preparing a patch for qemu-server to allow enabling the pcid
> >>>> cpuflag on a VM config level (especially since most VMs will run with
> >>>> kvm64, where changing the default is not an option!).
> >>>>
> >>>> switching it on by default for SandyBridge and co (which are missing it
> >>>> in Qemu, but support it technically) will likely happen with the move to
> >>>> Qemu 2.11, pending further feedback and review (it is not clear at all
> >>>> how various guest OS handle getting the flag changed out under them when
> >>>> migrating, and we don't want to integrate specific pinning support in a
> >>>> rushed through manner).
> >>>>
> >>>> for now you can of course just patch a hardcoded +pcid in to the cpu
> >>>> flag list on your hosts if you know your CPUs all support it and
> >>>> stop/start your VMs to regain lost performance.
> >>>>
> >>>
> >>> should be on pvetest for 5.x and 4.x shortly - please provide feedback!
> >>>
> >>> patches for exposing it somewhere on the GUI will follow (most likely
> >>> tomorrow).
> >>
> >> Thanks! I would love to see it as a default for the specific qemu cpu
> >> models.
> >>
> >> I mean we know exactly that sandybridge, ivybridge, ... support it or not?
> >>,
> > 
> > yes we do. but we are not 100% sure they won't cause problems when
> > live-migrating from without PCID to with PCID (on all guest operating
> > systems), and instead of introducing one-off pinning mechanisms for this
> > now in a rush, we give you a simple way (both from a code and from a
> > user perspective) to set it on all your VMs manually and trigger
> > shutdown/start cycles. the same option can be extended to support
> > selectively enabling or disabling other CPU flags in the feature (which
> > has been requested for non-security reasons a couple of times already).
> > 
> > the default for SandyBridge and co will likely be changed with the next
> > Qemu release (and accompagnying bump of machine type, which is already
> > integrated into our live-migration mechanism).
> 
> If i understand the patches correctly this means we can't use the old
> CPU models any longer but need to use Haswell-IBRS,
> Sandybridge-Haswell-IBRS, ...
> 
> See:
> http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg01562.html
> 
> and
> 
> http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg01563.html
> 
> Stefan

IBRS is for the Spectre mitigation. since those are new machine types,
they can get the PCID by default without any problems. the unclear ones
are the existing Sandybridge (and co) without IBRS.