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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

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

Jan

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

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