Comment # 11 on bug 1105536 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).