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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 12.09.06 11:50 >>>
>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.

Hm, I don't like this on-the-fly building of code very much, and I also don't
like writing assembly code that can obviously written to perform better. Also,
on 64-bits the code wouldn't look so much nicer since there's no {push,pop}ad.
But certainly, if you refuse to take the patch without changing that...

>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.

That sounds right (and better than the current way). I'll do that change,
though I guess I'd still not call it direct execution.

Jan

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