On Thursday 11 December 2014 22:20:06, Jonathan Gray wrote:
> On Wed, Dec 10, 2014 at 12:32:02AM +0100, Stefan Fritsch wrote:
> > For the codepatching part, the most interesting files are
> > codepatch.c and codepatch.h.  In copy.S and cpu.c, I convert the
> > code patching already done for SMAP to the new infrastructure (if
> > someone has a machine with SMAP support, testing would be nice).
> 
> There aren't so many machines with SMAP commercially released only
> a handful of "2 in 1" devices with Core M processors.
> 
> You should be able to test with the qemu support added by Intel
> however. ie
> qemu-system-x86_64 -cpu qemu64,+smap
> or
> qemu-system-x86_64 -cpu Broadwell

thanks for the info. I will try that.

> 
> > The basic approach is to create macros that surround a
> > to-be-patched code part and store pointer, length, and a tag in a
> > dedicated section. Then there are functions to replace all code
> > parts with a specific tag. Does this part of the diff look
> > sensible?
> 
> What about i386?  Though not included in your diff we can't assume
> the various multi byte nop sequences are valid there.
> 
> The Intel instruction set reference says:
> "The multi-byte NOP instruction performs no operation on supported
> processors and generates undefined opcode exception on processors
> that do not support the multi-byte NOP instruction."
> 
> It seems in practice they are supported on everything after
> 686/pentium pro?
> 
> Though the code doing the patching could do a cpuid check.

As first step, I would only commit amd64 support. If that works, we 
can split it into MI and MD parts and add support for other 
architectures. But the functions to replace code with NOPs or a 
function call will always be MD. When those are implemented for i386, 
one can include appropriate cpuid checks. But as there is no place to 
put MD code that is used by both amd64 and i386, there will probably 
be two similar but independent implementations for those two archs. Or 
do you see a better way?


Reply via email to