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

[Stefan Priebe - Profihost AG]

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