All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: "Tony Luck" <tony.luck@gmail.com>,
	"Reinette Chatre" <reinette.chatre@intel.com>,
	"Babu Moger" <Babu.Moger@amd.com>, X86-ML <x86@kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Fenghua Yu" <fenghua.yu@intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Jan H. Schönherr" <jschoenh@amazon.de>,
	"David Duncan" <davdunc@amazon.com>
Subject: Re: [PATCH] x86/intel_rdt: use rdmsr_safe() to workaround AWS host issue
Date: Thu, 10 Jan 2019 11:53:39 +0100	[thread overview]
Message-ID: <20190110105339.GC17621@zn.tnic> (raw)
In-Reply-To: <87woncol9s.fsf@vitty.brq.redhat.com>

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.

      reply	other threads:[~2019-01-10 10:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-20 13:40 [PATCH] x86/intel_rdt: use rdmsr_safe() to workaround AWS host issue Vitaly Kuznetsov
2018-12-20 16:17 ` Borislav Petkov
2018-12-20 17:31   ` Vitaly Kuznetsov
     [not found]   ` <51dcb13a-4751-47f5-1e01-f6731a2c6f3c@intel.com>
     [not found]     ` <20521afe-09af-7acf-6f32-3f6e9a971091@intel.com>
2019-01-09 11:39       ` Borislav Petkov
2019-01-09 12:09         ` Vitaly Kuznetsov
2019-01-09 12:14           ` Borislav Petkov
2019-01-09 18:41             ` Tony Luck
2019-01-10 10:32               ` Vitaly Kuznetsov
2019-01-10 10:53                 ` Borislav Petkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190110105339.GC17621@zn.tnic \
    --to=bp@alien8.de \
    --cc=Babu.Moger@amd.com \
    --cc=davdunc@amazon.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=jschoenh@amazon.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@gmail.com \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.