From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] enable port accesses with (almost) full register context Date: Tue, 12 Sep 2006 10:03:08 +0100 Message-ID: <450693EC.76E4.0078.0@novell.com> References: <45067AAA.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 12.09.06 09:53 >>> >On 12/9/06 8:15 am, "Jan Beulich" 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