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 _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
