From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sunset.davemloft.net (unknown [74.93.104.97]) by ozlabs.org (Postfix) with ESMTP id DF1B5DE148 for ; Mon, 29 Jan 2007 10:26:50 +1100 (EST) Date: Sun, 28 Jan 2007 15:26:48 -0800 (PST) Message-Id: <20070128.152648.75190891.davem@davemloft.net> To: ebiederm@xmission.com Subject: Re: [RFC/PATCH 0/16] Ops based MSI Implementation From: David Miller In-Reply-To: References: <1170015292.26655.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Cc: kyle@parisc-linux.org, linuxppc-dev@ozlabs.org, brice@myri.com, greg@kroah.com, shaohua.li@intel.com, linux-pci@atrey.karlin.mff.cuni.cz List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: ebiederm@xmission.com (Eric W. Biederman) Date: Sun, 28 Jan 2007 13:53:14 -0700 > The argument that we need to support what the RTAS is doing to support > other hypervisors seems to be a fallacy. What the RTAS is doing is > not sane from a hardware standpoint, so I do not expect it from other > virtualized/hypervisor style environments. > > If the hardware provides capabilities to isolate the MSI messages > properly it does not need to prevent us from touching the msi setup > registers. I disagree, I think you will find more systems, not less of them, doing something like RTAS. And as I stated in another email I believe sparc64 behaves the same way as RTAS. Account for these systems now, they exist and we need to support them properly. It's not a one-off kind of thing.