From: Andrew Cooper <andrew.cooper3@citrix.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: [PATCH 2/2] Guest L1D flush
Date: Thu, 9 Aug 2018 00:04:14 +0100 [thread overview]
Message-ID: <b2110c9c-2b6d-4106-e59b-85ca7c6c9d7f@citrix.com> (raw)
In-Reply-To: <CALMp9eSK=jeFH4Vg2rmd1prp1+Q=nyKCFw39K+SEj3k-Bh2qYg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
On 08/08/2018 23:20, speck for Jim Mattson wrote:
> 2018-08-08 14:21 GMT-07:00 speck for Konrad Rzeszutek Wilk <speck@linutronix.de>:
>> On Wed, Aug 08, 2018 at 12:15:06PM -0700, speck for Jim Mattson wrote:
>>> [patch 2/2] kvm: x86: Expose X86_FEATURE_FLUSH_L1D to kvm guests
>>>
>>> If this feature is available on the host, it can be exposed to a kvm
>>> guest.
>> Are you sure? I was reading the docs and nothing in it said to do this.
>>
>> In fact the doc suggests that this should not be done in the first place
>> and instead the ARCH_CAPABILITIES Bit 3 is to be exposed.
> Intel's white paper, "Description and mitigation overview for L1
> Terminal Fault" (337866-000) says:
>
> Each VMM can choose which CPU capabilities to make available to the
> guests under its control.
>
> ...and...
>
> A nested VMM that finds IA32_FLUSH_CMD is enumerated should check
> whether IA32_ARCH_CAPABILITIES bit 3 (SKIP_L1DFL_VMENTRY) is set,
> which indicates that it is not required to flush L1D on VMENTER.
>
> My reading of this is that:
>
> A) Exposing IA32_FLUSH_CMD to a guest is at the whim of the VMM, and
> B) There is actually no reason for a VMM to query
> IA32_ARCH_CAPABILITIES.SKIP_L1DFL_VMENTRY[bit 3] *unless*
> IA32_FLUSH_CMD is enumerated.
Per the current understanding, MSR_FLUSH_CMD functionality is only
needed by hypervisors (nested or otherwise). When SKIP_L1DFL is set,
nested hypervisors shouldn't need it themselves. However, there is
still a gaping HT-sized hole in the guaranteed-safety of this argument.
The absolute cost of using this MSR isn't terribly high (dispatch
serialising, and ~400 cycles to recover after), and yes - a guest can
waste time flushing its own L1D, but it can waste far more time by
needlessly VMExiting.
The important questions are 1) what is the cost of implementing the
functionality, and 2) how much are you willing to bet that it won't
become necessary for other reasons in the future.
I've implemented support in Xen for offering this functionality to
guests, because doing so is a whole 10 lines of code (inc. feature
levelling migration safety), and I'm not willing to take that bet.
~Andrew
prev parent reply other threads:[~2018-08-08 23:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-08 19:15 [MODERATED] [PATCH 2/2] Guest L1D flush Jim Mattson
2018-08-08 21:21 ` [MODERATED] " Konrad Rzeszutek Wilk
2018-08-08 22:20 ` Jim Mattson
2018-08-08 23:04 ` Andrew Cooper [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=b2110c9c-2b6d-4106-e59b-85ca7c6c9d7f@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=speck@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).