http://bugzilla.opensuse.org/show_bug.cgi?id=1105536 http://bugzilla.opensuse.org/show_bug.cgi?id=1105536#c1 --- Comment #1 from George Anchev --- *The system doesn't use a swap partition. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1105536 http://bugzilla.opensuse.org/show_bug.cgi?id=1105536#c3 --- Comment #3 from George Anchev --- [~]: grep "bits physical" /proc/cpuinfo address sizes : 36 bits physical, 48 bits virtual address sizes : 36 bits physical, 48 bits virtual address sizes : 36 bits physical, 48 bits virtual address sizes : 36 bits physical, 48 bits virtual address sizes : 36 bits physical, 48 bits virtual address sizes : 36 bits physical, 48 bits virtual address sizes : 36 bits physical, 48 bits virtual address sizes : 36 bits physical, 48 bits virtual I will send you the dmesg by email as it seems to reveal too much info which I don't understand fully and that's why I prefer not to have it publicly available long term. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1105536 http://bugzilla.opensuse.org/show_bug.cgi?id=1105536#c8 --- Comment #8 from George Anchev ---

the CPU physical limit is 64GB, motherboard might be less

In my case the CPU actually supports maximum 32GB: https://ark.intel.com/products/65719/Intel-Core-i7-3770-Processor-8M-Cache-u... So why would one need to add 'mem=32G'? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1105536 http://bugzilla.opensuse.org/show_bug.cgi?id=1105536#c11 --- Comment #11 from George Anchev --- Thanks for explaining! Testing with the new value suggested by you seems to work: [~]: dmesg | grep -i l1tf [~]: find /sys/devices/system/cpu/vulnerabilities/ -type f -print -exec /usr/bin/cat '{}' \; /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full generic retpoline, IBPB, IBRS_FW /sys/devices/system/cpu/vulnerabilities/spec_store_bypass Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: SMT vulnerable, L1D conditional cache flushes /sys/devices/system/cpu/vulnerabilities/spectre_v1 Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: PTI Does this mean there is an actual bug? IOW: is one supposed to use mem= workarounds and how could one know if one needs that? Also if I may ask: - Where does the exact value of 33554428k come from? (i.e. how do you calculate it) I am asking because when I calculate 2^35/1024 I get 33554432k (i.e. 4k more). - What do you mean "off-by-one error"? - What in the dmesg info says:

500MB of physical dimms are on "physical addresses" above 32GB

- Does the "mem=" value suggested by you result in using less RAM than what is usable physically available? I notice that before `free` showed 32874012 total, now it shows 32374300 which if I calculate correctly is 488Mb difference (not negligible). Also 32374300 != 33554428 (the mem value). I am just confused if the L1TF mitigation leads to a requirement of not using all available physical RAM (in which case I suppose this may qualify as a bug as it would mean not using efficiently the available hardware). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1105536 http://bugzilla.opensuse.org/show_bug.cgi?id=1105536#c14 --- Comment #14 from George Anchev --- Today I tried adding kvm-intel.enable_ept=0 to kernel boot command line however it didn't change the contents of: /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: SMT vulnerable, L1D conditional cache flushes The only effect of the boot parameter is that dmesg shows [ 9.643582] kvm_intel: unknown parameter 'enable_ept' ignored Is that a separate bug? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1105536 http://bugzilla.opensuse.org/show_bug.cgi?id=1105536#c16 --- Comment #16 from George Anchev --- Using kvm-intel.ept=0 gives /sys/devices/system/cpu/vulnerabilities/l1tf Mitigation: PTE Inversion; VMX: SMT vulnerable, L1D EPT disabled I don't know if "VMX: SMT vulnerable" is relevant considering: https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html#disabling-ept "Disabling EPT for virtual machines provides full mitigation for L1TF even with SMT enabled, because the effective page tables for guests are managed and sanitized by the hypervisor." i.e. it the contents of l1tf implies that the system is still vulnerable which kind of contradicts the documentation which says it is a full mitigation. I wasn't sure how to report that (separately or here). I hope someone can look into it. -- You are receiving this mail because: You are on the CC list for the bug.