WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [RFC, PATCH 16/24] i386 Vmi io header

To: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 16/24] i386 Vmi io header
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Wed, 15 Mar 2006 15:34:30 -0800
Cc: Andrew Morton <akpm@xxxxxxxx>, Joshua LeVasseur <jtl@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Virtualization Mailing List <virtualization@xxxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>, Dan Arai <arai@xxxxxxxxxx>
Delivery-date: Fri, 17 Mar 2006 10:41:52 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <m1acbrxv9v.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx>
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: <200603131811.k2DIBS8j005741@xxxxxxxxxxxxxxxxxxx> <m1acbrxv9v.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051201)
Eric W. Biederman wrote:
Zachary Amsden <zach@xxxxxxxxxx> writes:

Move I/O instruction building to the sub-arch layer.  Some very crafty
but esoteric macros are used here to get optimized native instructions
for port I/O in Linux be writing raw instruction strings.  Adding a
wrapper layer here is fairly easy, and makes the full range of I/O
instructions available to the VMI interface.

Also, slowing down I/O is not a useful operation in a VM, so there
is a VMI call specifically to allow making it a NOP.  I could find
no place where SLOW_IO_BY_JUMPING is still used, and consider it
obsoleted.  Even on older 386 systems, the I/O delay approximation
by touching the extra page register is likely to better.

This sounds like a prime candidate for the alternate instruction interfaces
and I don't see that being used here.

The problem is that floppy controllers and other crufty hardware actually do need those slowing port operations to work reliably. If you look at the usage of slow_down_io, you get scared pretty quick. If you want your driver to use it, you have the option of defining REALLY_SLOW_IO in your C file, then suffix your I/O calls with _p. The definition of SLOW_DOWN_IO actually used to be raw assembly instructions encapsulated in quotations. I just realized this does actually change the semantics of drivers/net/de600.c, which really is the only driver which defines SLOW_IO_BY_JUMPING.

This usage of predefined macros in the driver causing port I/O semantics to change seems a little strange to try to wrap onto an alternate instruction interfaces, since it is dependent definitions local to each .C file, rather than global processor or derived feature bits.

The VMI call wrappers are very much similar to the alternate instruction interfaces - they just leave the alternative to be defined by the hypervisor.

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

<Prev in Thread] Current Thread [Next in Thread>