This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] enable port accesses with (almost) full register context
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Tue, 12 Sep 2006 10:03:08 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Sep 2006 02:02:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C12C25FF.14F8%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <45067AAA.76E4.0078.0@xxxxxxxxxx> <C12C25FF.14F8%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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.


Xen-devel mailing list