Re: Reducing the Number of Context-Sensitive Macros in x86_emulate.c

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 20/04/16 17:42, John McDermott wrote:
> Xen Developers,
>
> Would there be any interest in replacing some of the
> context-sensitive macros in x86_emulate.c, to make it more
> maintainable?
>
> I work on the Xenon project, which researches ways to transform
> Xen into a higher-security hypervisor. One of the things we do is
> modify Xen code to make it more maintainable. As part of that
> work, we have some experience in improving the maintainability of
> x86_emulate.c.
>
> The design of the x86_emulate function depends on labels in such
> a way that it is probably not practical to remove _all_
> context-sensitive macros. The code could be made more
> maintainable by reducing the number. The ultimate goal would be
> to have only 2 context-sensitive macros, say “chk” and “chkw”,
> referencing the global labels. Everything else would be static
> always_inline functions. This would separate the
> context-sensitive macro concerns into a small amount of code and
> reduce the number of macros in the code. (Two context-sensitive
> macros would be needed because one needs to reference only the
> label “done" but the other needs to reference the label
> “writeback".)
>
> If there is some interest, we could submit a series of patches,
> each one replacing a single context-sensitive macro in the
> code.

I have been wanting to do this for a while.  An item was discussed at
Xen Hackathon (two days ago) which involves rewriting x86_emulate().

The primary motivation is to split instruction decode from emulate, to
be able to have an audit stage in the middle.  A side effect of this is
that we can remove 4 of our 5 pieces of code which currently do x86
instruction prefix decoding (each slightly differently).  A second
motivation is to address the lack of support for non-memory-target
instructions, which is an issue for introspection activities.

Rest assured that I dislike the code as much as you do, and I plan for
the result to be far easier to follow and maintain.

Shortly, I will be submitting notes from that session, and a design
showing how I plan to proceed.

~Andrew

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