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 12:28:17 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Sep 2006 04:27:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4506A8D7.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: AcbWXorDyQm1yUJREdu5hwAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] enable port accesses with (almost) full register context
User-agent: Microsoft-Entourage/
On 12/9/06 11:32, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

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

IMO you're doing code building anyway, but just of one instruction. You get
rid of the locking by doing it to a per-CPU buffer, and the stack is the
obvious place, calling out to register save/restore code. I don't really
care about the performance of the save/restore code -- it's obviously going
to be trivial compared with the unavoidable trap-and-emulate cost. Also, do
you need separate save/restore code for IN vs. OUT instructions?

Something like:
    call save_host_restore_guest
    <IN or OUT>
    call save_guest_restore_host

Would that be reasonable?

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

'Special' is a crappy description because it's so non-specific. How about
'BIOS' ports? I can't think of any reason that emulating these accesses
could be a problem, except that BIOS/firmware is trapping them and expecting
more context than the hardware instruction defines as being required.

Alternatively, perhaps we could get rid of the distinction and emulate all
port accesses in this way? I suspect that the cost of state save/restore and
building the trampoline is dwarfed by the cost of the GPF and even the cost
of the I/O port access itself (they don't tend to be super fast). Could you
do a few quick measurements to determine this? If the extra cost is less
than, say, 10%, I'd be inclined to take the hit to avoid interface changes.

 -- Keir

Xen-devel mailing list