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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 12.09.06 09:53 >>>
>On 12/9/06 8:15 am, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> That is because of the self modifying code that needs proper MP
>> synchronization. I know it's looking ugly, but I considered this the most
>> reasonable approach.
>
>Why is more synchonisation needed for emulation of these SMI port accesses
>than you'd have for direct execution? I.e., if the accesses were executed
>natively on an SMP system there'd be none of the extra synchronisation you
>added happening. The instructions would be directly executed.

Again, I'm using self-modifying code there (to store the port number, as I
can't reliably use %dx for it if the original instruction happened to be one
with immediate operand, and %edx/%rdx happens to carry relevant data
for the SMI handler), which is what needs synchronization.

>> I considered that too, but rejected it because of opening these ports to
>> vm86 mode then, too (as I/O instructions are *not* susceptible to iopl there,
>> they only depend on the bitmap).
>
>I/O bitmap always overrides IOPL, in every execution mode. Why is vm86 mode
>a particular concern? I was thinking that dom0 would switch on the direct

You're right, of course - all modes are relevant here.

>bitmap access only for the process(es) that requested it. We wouldn't want
>direct access to be available to every process in dom0.

True. With that I agree installing the bitmap in the TSS would allow solving
the problem, too. Still I think the necessary overhead (you'd need to copy
the bitmap and keep it sync-ed, or make it read-only, for the direct access
to not be abusable) would be larger than using the special access method.

>Not that I'm certain direct access is better than 'special emulation'. But
>I'm not applying the existing patch unless I understand exactly why it needs
>to do everything that it does. I'm in no rush -- supporting some piece of HP
>closed-source management software isn't top priority for us, I'd say.

Which I can easily understand; nevertheless I seem to recall that we had
talked about the issue when it was first brought up (at least 3 months back),
and you seemed in agreement that the nature of the problem warrants a fix.

Jan

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