From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: pvops: AHCI problems with SB600 Date: Thu, 24 Sep 2009 17:36:09 -0400 Message-ID: <20090924213609.GB18306@phenom.dumpdata.com> References: <20090922140825.GB21736@phenom.dumpdata.com> <20090923120646.GA3199@phenom.dumpdata.com> <4ABA7578.8030201@goop.org> <20090923193245.GA5682@phenom.dumpdata.com> <4ABA8088.1080807@goop.org> <4ABA8574.2060501@goop.org> <20090923212457.GA5816@phenom.dumpdata.com> <4ABA9980.1020007@goop.org> <20090924124415.GA9056@phenom.dumpdata.com> <4ABBB914.8010800@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4ABBB914.8010800@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Patrick Scharrenberg , Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, Sep 24, 2009 at 11:23:16AM -0700, Jeremy Fitzhardinge wrote: > On 09/24/09 05:44, Konrad Rzeszutek Wilk wrote: > > There was a lot of havoc - all of the PCI BARs were useless. Is the MFN > > (from the pfn_to_mfn on this address) suppose to have a specific value? > > > > Not sure. pfn_to_mfn is never supposed to happen on ioremap phys addrs, > because of _PAGE_IOMAP in the pte. Its probably worth checking that > _PAGE_IOMAP is actually getting set. I found the problem. I did not power off the machine after doing a non-Xen boot where the GART was used. I am not entirely sure what the GART was doing, but pretty much all writew/readw were not doing/going where they were suppose to. > > > For all of those setting, no_iommu=1 should do the trick. But in reality > > I need to double-check that: > > > > > > diff --git a/arch/x86/xen/pci-swiotlb.c b/arch/x86/xen/pci-swiotlb.c > > index 00f2260..390f698 100644 > > --- a/arch/x86/xen/pci-swiotlb.c > > +++ b/arch/x86/xen/pci-swiotlb.c > > @@ -989,6 +989,8 @@ void __init xen_swiotlb_init(void) > > xen_swiotlb_init_with_default_size(64 * (1<<20)); /* default to 64MB */ > > dma_ops = &xen_swiotlb_dma_ops; > > iommu_detected = 1; > > + no_iommu = 1; /* Forces the other IOMMU (if they are detected) to > > + to quit, rather than initialize. */ > > #ifdef CONFIG_GART_IOMMU > > gart_iommu_aperture_disabled = 1; > > #endif > > > > I think I need to rethink this swiotlb-Xen part. This is starting > > to look like a hack. > > > > It isn't great. We need a way to either layer or arbitrate between > these different address translation mechanisms. I am sending another patch that I think is more nicer, and it takes care of the other IOMMUs. > > >> Another thought, could we actually use the gart iommu instead of swiotlb > >> if it is available? I think it leads to exactly the same set of issues > >> as extending normal swiotlb for Xen's use (ie, inserting pfn->mfn > >> conversion into the correct places, and perhaps allocating the memory > >> properly). Worth thinking about; it may shine light on better ways to > >> fix up swiotlb. > >> > > Yes! That was my next step - see if it is possible to use it and if so > > extend it for that purpose (and without any ghastly #ifdef). > > > > Good. Still thinking about this ..