Messages in this thread | | | Date | Thu, 10 Jan 2019 11:53:39 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH] x86/intel_rdt: use rdmsr_safe() to workaround AWS host issue |
| |
On Thu, Jan 10, 2019 at 11:32:47AM +0100, Vitaly Kuznetsov wrote: > The other thing is: how can we be sure that there's no hypervisor > exposing these feature already? Even if open-source hypervisors like > KVM/Xen don't do it it doesn't prove anything: there are numerous > proprietary hypervisors and who knows what they do.
Well, we have this thing called CPUID which enumerates features - regardless of running on baremetal or on a hypervisor. But apparently some Intel CPUs dropped the ball there. Which caused the f*ckup we are in right now.
If you really want to not foreclose that feature for guests - and it sounds like you do - the other thing I can think of is an early quirk *setting* those feature bits for those Intel CPUs which "forgot" to set them and then changing the resctrl code to test CPUID bits first.
This way, the kernel is presented with a unified view on what is supported by the underlying machine - and that machine can be a HV or baremetal - kernel doesn't care.
> The original issue which triggered the discussion was discovered on > AWS Xen where the host is buggy and I suggested a simple short-term > workaround
And I'm sick'n'tired of simple-short term workarounds and band-aids and the kernel always bending because people dropped the ball and those being perpetuated, because, sure, we'll add one more "fix" on the pile, who cares... :-\
If AWS xen is broken, then that should be fixed - not the kernel.
-- Regards/Gruss, Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
| |