>>> On 05.02.18 at 19:04, wrote:
> But as you correctly pointed out, it was a very long way from being
> complete. We currently have no idea whether we are in NMI context, so
> arranging not to not execute an iret is hard.
As long as we don't mean to patch extremely early or extremely
late parts
On 05/02/18 16:20, Jan Beulich wrote:
On 05.02.18 at 16:16, wrote:
>> On 05/02/18 14:09, Jan Beulich wrote:
>> On 05.02.18 at 11:24, wrote:
During patching, there is a very slim risk that an NMI or MCE interrupt in
the
middle of altering the code in the NMI/MCE paths, in
On Mon, Feb 05, 2018 at 10:24:58AM +, Andrew Cooper wrote:
> During patching, there is a very slim risk that an NMI or MCE interrupt in the
> middle of altering the code in the NMI/MCE paths, in which case bad things
> will happen.
>
> The NMI risk can be eliminated by running the patching loo
>>> On 05.02.18 at 16:16, wrote:
> On 05/02/18 14:09, Jan Beulich wrote:
> On 05.02.18 at 11:24, wrote:
>>> During patching, there is a very slim risk that an NMI or MCE interrupt in
>>> the
>>> middle of altering the code in the NMI/MCE paths, in which case bad things
>>> will happen.
>>>
>
On 05/02/18 14:09, Jan Beulich wrote:
On 05.02.18 at 11:24, wrote:
>> During patching, there is a very slim risk that an NMI or MCE interrupt in
>> the
>> middle of altering the code in the NMI/MCE paths, in which case bad things
>> will happen.
>>
>> The NMI risk can be eliminated by runnin
>>> On 05.02.18 at 11:24, wrote:
> During patching, there is a very slim risk that an NMI or MCE interrupt in the
> middle of altering the code in the NMI/MCE paths, in which case bad things
> will happen.
>
> The NMI risk can be eliminated by running the patching loop in NMI context, at
> which
During patching, there is a very slim risk that an NMI or MCE interrupt in the
middle of altering the code in the NMI/MCE paths, in which case bad things
will happen.
The NMI risk can be eliminated by running the patching loop in NMI context, at
which point the CPU will defer further NMIs until pa
