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

Re: [Xen-devel] pvops: AHCI problems with SB600

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] pvops: AHCI problems with SB600
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 24 Sep 2009 11:23:16 -0700
Cc: Patrick Scharrenberg <pittipatti@xxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 24 Sep 2009 11:23:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090924124415.GA9056@xxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20090921150634.GD20933@xxxxxxxxxxxxxxxxxxx> <4AB89227.8050302@xxxxxx> <20090922140825.GB21736@xxxxxxxxxxxxxxxxxxx> <20090923120646.GA3199@xxxxxxxxxxxxxxxxxxx> <4ABA7578.8030201@xxxxxxxx> <20090923193245.GA5682@xxxxxxxxxxxxxxxxxxx> <4ABA8088.1080807@xxxxxxxx> <4ABA8574.2060501@xxxxxxxx> <20090923212457.GA5816@xxxxxxxxxxxxxxxxxxx> <4ABA9980.1020007@xxxxxxxx> <20090924124415.GA9056@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
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
>
> <sigh>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


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

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