>>> 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
xen-x86-io-register-context-3.patch
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home