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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 13.09.06 14:10 >>>
>On 13/9/06 10:46, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> It would, provided the above assumption about the need to modify the
>> output value would never become true.
>
>I hope it doesn't. :-) We'll cross this bridge if we come to it.

It'll be immediately needed if string I/O instructions are to also go that
path, unless you'd want them to access the original user buffer (and
trap the eventual page fault).

Also, I might need a little more clarification on the stack (ab)use for
creating stubs: As I understand it, the double-fault and NMI stacks on
x86-64 are currently simply overlaid on top of the normal stack,
basically assuming you'd never use this much space (the one-page
non-present separator is inserted only in debug builds). (Side note:
While for normal operations this is fine, I question the value of a
double fault backtrace that might be created due to a stack overflow
on a non-debug build. The obvious question is why the separator hole
isn't always being created - after all this is a one time operation that
happens as CPUs get brought up, so there shouldn't be any
performance overhead.)

Anyway, the relationship to the stubs is that I would favor moving the
stubs onto the double fault stack itself (rather than adjacent to the NMI
stack, which in turn is adjacent to the double fault one), because
(a) the stubs won't be needed anymore once the double fault stack is
needed and
(b) the stubs are this way farther away from the normal stack, making
it less likely for difficult to debug problems to crop in. I would then
similarly put the 32-bit I/O stubs onto the (top of the) (would-be
double fault) stack (which should be per CPU as much as on 64-bits,
but I realize that would imply per-CPU double fault TSSes and hence
per-CPU GDTs).

Jan

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