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: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] enable port accesses with (almost) full register context
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 12 Sep 2006 08:53:19 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Sep 2006 01:03:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45067AAA.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbWQIL1wT6KxUIzEdutkAANk04WTA==
Thread-topic: [Xen-devel] [PATCH] enable port accesses with (almost) full register context
User-agent: Microsoft-Entourage/
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.

> 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
bitmap access only for the process(es) that requested it. We wouldn't want
direct access to be available to every process in dom0.

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.

 -- Keir

Xen-devel mailing list