Messages in this thread | | | Date | Fri, 4 Jan 2013 14:02:18 -0700 | Subject | Re: [PATCH v7u1 26/31] x86: Don't enable swiotlb if there is not enough ram for it | From | Shuah Khan <> |
| |
On Fri, Jan 4, 2013 at 1:34 PM, Yinghai Lu <yinghai@kernel.org> wrote: > On Fri, Jan 4, 2013 at 9:50 AM, Shuah Khan <shuahkhan@gmail.com> wrote: >> >> This change doesn't take into account what swiolb was when >> pci_swiotlb_detect_override() is called. Instead of returning >> use_swiotlb like the original code did, it returns swiotlb which could >> be zero, if !enough_mem_for_swiotlb(). >> >> Might work fine on Intel platforms, but not on systems where the IOMMU >> driver wants to enable swiotlb for some devices as in the case of AMD. >> >> AMD IOMMU driver enables swiotlb for devices that are not specified in >> IVRs and/or not in the AMD IOMMU scope, after it successfully >> initializes IOMMU. It will explicitely set switolb=1 to make sure >> reserved swiotlb memory is not released. This change will break that >> case. > > in that case, we have to panic.... > > please check attached patch. > > Also for those kind of systems, users must specify crashkernel_low=72M or > what ever for kdump.
Pani'cing the system doesn't sound like a good option to me in this case. This change to disable swiotlb is made for kdump. However, with this change several system fail to boot, unless crashkernel_low=72M is specified.
I would the say the right approach to solve this would be to not change the current pci_swiotlb_detect_override() behavior and treat swiotlb =1 upon entry equivalent to swiotlb_force set.
Thanks, -- Shuah
| |