|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] pvops: AHCI problems with SB600, (continued)
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Jeremy Fitzhardinge
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Jeremy Fitzhardinge
- Re: [Xen-devel] pvops: AHCI problems with SB600, Jeremy Fitzhardinge
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Jeremy Fitzhardinge
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600,
Jeremy Fitzhardinge <=
- Re: [Xen-devel] pvops: AHCI problems with SB600, Konrad Rzeszutek Wilk
- Re: [Xen-devel] pvops: AHCI problems with SB600, Patrick Scharrenberg
Re: [Xen-devel] Announcing xen/master: pvops git trees rearranged (AMD tests?), Konrad Rzeszutek Wilk
Re: [Xen-devel] Announcing xen/master: pvops git trees rearranged, Pasi Kärkkäinen
|
|
|
|
|