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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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?

> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel