Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1761644imu; Thu, 10 Jan 2019 02:34:43 -0800 (PST) X-Google-Smtp-Source: ALg8bN7/dg1TipCRC3IGMgJKpzi7PkK8+Z8rvYphYZ+BwE1uAxfLVRwK2ukBNJaPh18yZNltBoJ8 X-Received: by 2002:a17:902:7005:: with SMTP id y5mr9864114plk.7.1547116483489; Thu, 10 Jan 2019 02:34:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547116483; cv=none; d=google.com; s=arc-20160816; b=NW9yGcwb04mi1rH4oIYwENNZURj9oOT2soAC0uOxJWOX7v/W+Ak/hOGf/K4oXgsMUN XDU0O9BQav0nSbYYApNz69boN8wfu5+98zBuZO2UcdyqIvXUpRdEPT4MYB52ReoDq4GE lm1KrkNm/dXfgaN0lxqhHyhR5w3OzjEmny8N/bMQL7FwqbMPwKDdMzYCS0D1gDxdouSh MvGufBLZ3HySOhTTnHpl4DiWz2ocuCuzGzJT7rE9ElsOuIhhdSbyYC1kwueJHqDGOEOt MViz+4kYM4z0RFz7aVQ8vJjWoaVxcFUS0EkM6hVGKWpWLidqA9SuHuiunNb6T7+K3fyD Q/tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=wUJ0PAnWAeJ1S7Ef687fOQGcmSNaBVcqY8ROm1pICGA=; b=fCToaJGd60McULdX0iZPJld6K7e7F4a0Y/241yTCYehV4CQp7hzhZVOHss8xHQDpUq R/PDsiizLSx8txnqFUfxc27fMO57TJ5O+qoK5mblrMdcwUuOdvMVsuJAp4os/1NCromG Hg4L6GQ2wIfHUMQrzl8aXz4EP0USxglRAA4hOM/N2JzYM9NjGF3roqset+MvpDLOrcGI t0VjjbinIRIEJS4zP4+SWDMKae++w6SIxnpTJeSrIE6IGhhWoOtAil/yKvKcSRdTS4aL avg0ALCxUMg0SfT9HgLTG/kiYhA+zepGHFiyIvIL60PiILu5aFVy5AyFOlNgRToPYeZP sHTA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e4si13695474pgd.256.2019.01.10.02.34.28; Thu, 10 Jan 2019 02:34:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728173AbfAJKcw (ORCPT + 99 others); Thu, 10 Jan 2019 05:32:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44098 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726951AbfAJKcv (ORCPT ); Thu, 10 Jan 2019 05:32:51 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 60C0C7970A; Thu, 10 Jan 2019 10:32:51 +0000 (UTC) Received: from vitty.brq.redhat.com.redhat.com (unknown [10.43.2.155]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E466A672C4; Thu, 10 Jan 2019 10:32:48 +0000 (UTC) From: Vitaly Kuznetsov To: Tony Luck , Borislav Petkov Cc: Reinette Chatre , Babu Moger , X86-ML , Linux Kernel Mailing List , Fenghua Yu , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , =?utf-8?Q?Jan_H=2E_Sch=C3=B6nherr?= , David Duncan Subject: Re: [PATCH] x86/intel_rdt: use rdmsr_safe() to workaround AWS host issue In-Reply-To: References: <20181220134046.7916-1-vkuznets@redhat.com> <20181220161722.GD31403@zn.tnic> <51dcb13a-4751-47f5-1e01-f6731a2c6f3c@intel.com> <20521afe-09af-7acf-6f32-3f6e9a971091@intel.com> <20190109113915.GB15665@zn.tnic> <87bm4qoww4.fsf@vitty.brq.redhat.com> <20190109121445.GC15665@zn.tnic> Date: Thu, 10 Jan 2019 11:32:47 +0100 Message-ID: <87woncol9s.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 10 Jan 2019 10:32:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tony Luck writes: > On Wed, Jan 9, 2019 at 5:00 AM Borislav Petkov wrote: >> >> On Wed, Jan 09, 2019 at 01:09:31PM +0100, Vitaly Kuznetsov wrote: >> > Hm, why is that? In theory, hypervisors can pass through or emulate the >> > required MSRs... >> >> ...and when the theory becomes reality we'll remove the check. > > In practice that may be a long time coming. We don't have many CLOSIDs, or > bits in a cache mask, at the h/w level. If you start trying to > subdivide those resources to pass a subset to a guest, then you'll > quickly find that you have no flexibility in the guest to do anything > useful. It would only work if you limited to two, or perhaps three > guests. Running a single guest on a physical CPU is a very common scenario. In fact, sharing cores is very rare for public clouds: e.g. all worthy instance types on AWS/Azure give you dedicated cores and I don't see why hypervisor can't pass through resctl features. 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. 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, I'm no expert in rdt/qos so I'm leaving this up to the maintainers to decide which fix deserves to go in (if any). -- Vitaly