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

[Stefan Priebe - Profihost AG]

Am 10.01.2018 um 08:08 schrieb 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.

Yes sure i just wanted to say that qemu itself does not plan to extend
the existing types.

> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>