Re: [Xen-devel] [PATCH] enable port accesses with (almost) full register context

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 12/9/06 10:03, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Again, I'm using self-modifying code there (to store the port number, as I
> can't reliably use %dx for it if the original instruction happened to be one
> with immediate operand, and %edx/%rdx happens to carry relevant data
> for the SMI handler), which is what needs synchronization.

Ok, I see. I think it would be neater to build the code on the stack, or
some other per-cpu area, and avoid the synchronisation. We have no plans to
use the PAGE_NX flag in Xen itself, and x86/64 already has stack
trampolines. Perhaps the register save/restore code could be tidied too,
since it's not performance critical. It's not at all uniform like I'd
expect, with those interleaved push/pop/mov instructions. How about
something more like:
 pushad; call restore_guest_regs; <I/o port access>; popad
Where restore_guest_regs takes a regparm, and (obviously) restores the
regparm register last. I'd only do it as a call because it'd be ugly to
dynamically build that amount of code.

I'm not sure about the full extent of the interface changes either. How
about we add a new sysctl for specifying ports which need 'direct
execution'. It makes sense to make it a sysctl because this is a property of
the I/O port (or assumptions about it encoded in the platform firmware)
rather than a per-domain issue, or something that I think should be visible
at the physdev_op interface.

We'd test the per-port direct-execution flag for any port access by any
domain. After all, the only reason we don't use the new code for *all* port
accesses is concern about performance. I think calling this 'direct
execution' versus 'emulation' at the interface is fair -- even though we
emulate in all cases, in the former case it will be Xen's responsibility to
do all that is necessary to make it appear to the BIOS that the instruction
was executed directly, as when running natively.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel