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: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] enable port accesses with (almost) full register context
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 12 Sep 2006 10:50:46 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Sep 2006 02:49:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <450693EC.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbWUOtMKbtvFkJEEduiGQAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] enable port accesses with (almost) full register context
User-agent: Microsoft-Entourage/
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