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

[Jan Beulich <jbeulich@xxxxxxxx>]

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?

Jan