[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.