From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: pvops: AHCI problems with SB600 Date: Thu, 24 Sep 2009 11:23:16 -0700 Message-ID: <4ABBB914.8010800@goop.org> References: <20090921150634.GD20933@phenom.dumpdata.com> <4AB89227.8050302@web.de> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090924124415.GA9056@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: Patrick Scharrenberg , Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org 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. > 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. >> 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. J