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

Re: [Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

On 22/01/18 12:06, Jan Beulich wrote:
>>>> On 22.01.18 at 12:42, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 19/01/18 13:51, Jan Beulich wrote:
>>>>>> On 19.01.18 at 14:36, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> On 19/01/18 11:43, Jan Beulich wrote:
>>>>>>>> On 18.01.18 at 16:46, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>>> @@ -729,6 +760,9 @@ ENTRY(nmi)
>>>>>>  handle_ist_exception:
>>>>>>          SAVE_ALL CLAC
>>>>>> +        SPEC_CTRL_ENTRY_FROM_INTR /* Req: %rsp=regs, Clob: acd */
>>>>>> +        /* WARNING! `ret`, `call *`, `jmp *` not safe before this 
>>>>>> point. */
>>>>> Following my considerations towards alternative patching to
>>>>> eliminate as much overhead as possible from the Meltdown
>>>>> band-aid in case it is being disabled, I'm rather hesitant to see any
>>>>> patchable code being introduced into the NMI/#MC entry paths
>>>>> without the patching logic first being made safe in this regard.
>>>>> Exceptions coming here aren't very frequent (except perhaps on
>>>>> hardware about to die), so the path isn't performance critical.
>>>>> Therefore I think we should try to avoid any patching here, and
>>>>> just conditionals instead. This in fact is one of the reasons why I
>>>>> didn't want to macro-ize the assembly additions done in the
>>>>> Meltdown band-aid.
>>>>> I do realize that this then also affects the exit-to-Xen path,
>>>>> which I agree is less desirable to use conditionals on.
>>>> While I agree that our lack of IST-safe patching is a problem, these
>>>> alternative points are already present on the NMI and MCE paths, and
>>>> need to be.  As a result, the DF handler is in no worse of a position. 
>>>> As a perfect example, observe the CLAC in context.
>>> Oh, indeed. We should change that.
>>>> I could perhaps be talked into making a SPEC_CTRL_ENTRY_FROM_IST variant
>>>> which doesn't use alternatives (but IMO this is pointless in the
>>>> presence of CLAC), but still don't think it is reasonable to treat DF
>>>> differently to NMI/MCE.
>>> #DF is debatable: On one hand I can see that if things go wrong,
>>> it can equally be raised at any time. Otoh #MC and even more so
>>> NMI can be raised _without_ things going (fatally) wrong, i.e. the
>>> patching may break a boot which would otherwise have succeeded
>>> (whereas the #DF would make the boot fail anyway).
>> I don't see a conclusion here, or a reason for treating #DF differently
>> to NMI or #MC.
> Odd - I thought my reply was pretty clear in this regard.

The clear way of replying would be "Yes - please put in conditionals for


Xen-devel mailing list



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