[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/intel: Expose MSR_ARCH_CAPS to dom0



On 28.08.2020 18:38, Andrew Cooper wrote:
> On 28/08/2020 17:17, Jan Beulich wrote:
>> On 28.08.2020 18:09, Andrew Cooper wrote:
>>> On 28/08/2020 16:42, Jan Beulich wrote:
>>>> On 28.08.2020 12:23, Andrew Cooper wrote:
>>>>> On 28/08/2020 09:41, Jan Beulich wrote:
>>>>>> On 27.08.2020 21:37, Andrew Cooper wrote:
>>>>>>> The overhead of (the lack of) MDS_NO alone has been measured at 30% on 
>>>>>>> some
>>>>>>> workloads.  While we're not in a position yet to offer MSR_ARCH_CAPS 
>>>>>>> generally
>>>>>>> to guests, dom0 doesn't migrate, so we can pass a subset of hardware 
>>>>>>> values
>>>>>>> straight through.
>>>>>>>
>>>>>>> This will cause PVH dom0's not to use KPTI by default, and all dom0's 
>>>>>>> not to
>>>>>>> use VERW flushing by default,
>>>>>> To avoid VERW, shouldn't you also expose SKIP_L1DFL?
>>>>> SKIP_L1DFL is a software-only bit, specifically for nested virt.
>>>>>
>>>>> It is for Xen to tell an L1 hypervisor "you don't need to flush on
>>>>> vmentry because I'm taking care of it".
>>>> Or for a hypervisor underneath us to tell us, which we could then
>>>> hand on to Dom0?
>>> For dom0 to do what with?
>>>
>>> PV guests can't use the VMLAUNCH/VMRESUME instruction at all, and it is
>>> not currently possible to configure nested virt for a PVH dom0 to use.
>> Aren't they also using this on the exit-to-user-mode path, like we
>> do on exit-to-PV? And in certain cases when idle?
> 
> MSR_FLUSH_CMD is used used for VMEntry.  This flushes the L1D cache, and
> was to combat L1TF.  Native systems don't flush the L1D at all, and
> invert PTEs instead as a *far* lower overhead mitigation.
> 
> Then MDS came along.  VERW is used to flush the uarch buffers.  This
> needs doing in all return-to-guest contexts.
> 
> As VMEntry needs both, MSR_FLUSH_CMD's behaviour was extended to cover
> both the L1D cache and uarch buffers, so software didn't have to arrange
> for both.
> 
> Therefore, the overall mitigations are VERW on exit-to-PV, and
> MSR_FLUSH_CMD on exit-to-HVM.
> 
> 
> There is no current need for native setups to use MSR_FLUSH_CMD.  The
> only reason we expose the MSR to HVM guests is for nested-virt.

But the question was about the use of VERW on exit-to-user paths in
a PV kernel, which I apparently wrongly understood SKIP_L1DFL also
indicates to be unnecessary. I'm sorry for the confusion. So
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.