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: Mon, 18 Sep 2006 15:10:51 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 18 Sep 2006 07:10:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C12C5861.1215%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: <4506A8D7.76E4.0078.0@xxxxxxxxxx> <C12C5861.1215%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 12.09.06 13:28 >>>
>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
>    ret
>Would that be reasonable?

Attaching the revised patch.

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

The new measurement results (full context compared to normal emulation):

PentiumIII (32-bit)     88%
Pentium4 (64-bit)       90%


Attachment: xen-x86-io-register-context-3.patch
Description: Text document

Xen-devel mailing list