Re: [Xen-devel] [PATCH v3 07/23] xsplice: Implement support for applying/reverting/replacing patches. (v5)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.02.16 at 22:10, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 23/02/2016 20:41, Konrad Rzeszutek Wilk wrote:
>> . snip..
>>>> + * Note that because of this NOP code the do_nmi is not safely patchable.
>>>> + * Also if we do receive 'real' NMIs we have lost them.
>>> The MCE path needs consideration as well.  Unlike the NMI path however,
>>> that one cannot be ignored.
>>>
>>> In both cases, it might be best to see about raising a tasklet or
>>> softirq to pick up some deferred work.
>> I will put that in a seperate patch as this is patch is big enough.
> 
> Actually, after subsequent thought, raising a tasklet wont help.
> 
> The biggest risk is the SMAP alternative in the asm entrypoints.  The
> only way patching that can be made safe is to play fun and games with
> debug traps. i.e.
> 
> Patch a 0xcc first
> Then patch the rest of the bytes in the replacement
> Then replace the 0xcc with the first byte of the replacement
> 
> This way if the codepath is hit while patching is in progress, you will
> end up in the debug trap handler rather than executing junk.  There then
> has to be some scheduling games for the NMI/MCE handler to take over
> patching the code if it interrupted the patching pcpu.  Patching in
> principle is a short operation, so performing it the handlers is not too
> much of a problem.
> 
> The tricky part is patching the top of the debug trap handler and not
> ending in an infinite loop.  I have a cunning idea, and will see if I
> can find some copious free time to experiment with.

For the SMAP patching this isn't the only way to make it safe, but
the alternative isn't suitable for xSplice: As long as the original
code is just NOPs, and as long as the starting address is aligned,
the first two bytes could become a short branch instead, patching
would fiddle with everything except the first two bytes first, and
as its last action (suitably fenced and maybe even cache flushed)
would atomically overwrite the first two bytes.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel