This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] enable port accesses with (almost) full register context
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Tue, 12 Sep 2006 11:32:23 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Sep 2006 03:31:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C12C4186.11FD%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <450693EC.76E4.0078.0@xxxxxxxxxx> <C12C4186.11FD%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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.


Xen-devel mailing list