From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Permissive devices in Xen Date: Sun, 08 Jul 2007 11:10:12 +0100 Message-ID: References: <20070708100044.GX3885@ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070708100044.GX3885@ics.muni.cz> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Lukas Hejtmanek Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 8/7/07 11:00, "Lukas Hejtmanek" wrote: >> domU is not trusted to manage the i/o address space. We assume dom0 has set >> up the values sanely and domU should have no reason to change them. > > OK, I see. But there is problem with, e.g., InfiniBand card that during > initialization performs reset of the card. The reset destroys the PCI config > space therefore the driver reads 16 dwords from the config space and after > reset, it writes them back. In DomU, it obviously does not restore address > bars and the device fails to respond via MMIO. > > So, I've tried to allow DomU (via pciback driver) to write also the address > bars but in this case, I'm facing to huge SLAB corruptions. In Dom0 or non-Xen > kernel, it works pretty well. > > Do you have any hints how to track it down? This was tracked down by Alex Williamson some time ago. There is code in drivers/xen/pciback/conf_space_capability_pm.c:pm_ctrl_write() to restore bars after a D3->D0 transition. I guess either your kernel does not have that fix, or the fix needs to be extended slightly to cover whatever case you are seeing. -- Keir