Re: [PATCH v7u1 26/31] x86: Don't enable swiotlb if there is notenough ram for it

[Shuah Khan]

On Fri, Jan 4, 2013 at 4:00 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
> On Fri, Jan 4, 2013 at 2:56 PM, Shuah Khan <shuahkhan@xxxxxxxxx> wrote:
>>
>> AMD IOMMU driver is using this lever to leave swiotlb enabled when it
>> detects devices that can't be supported by iommu. My concern is that
>> this change for kdump removes that handshake ability between iommu and
>> swiolb.
>
> No, it does not remove that ability.
>
> I'd like to see the boot log on system that could be affected by this patch.

You are in luck. I am testing iommu on an AMD system as we speak. I
also enabled amd_iommu_dump for AMD-Vi table dump.

[    3.198194] pci 0000:00:00.2: irq 72 for MSI/MSI-X
[    3.198259] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40
[    3.264727] AMD-Vi: Lazy IO/TLB flushing enabled

You can see here that AMD IOMMU is enabled.

[    3.264733] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    3.264738] Placing 64MB software IO TLB between ffff8800b9ddb000 -
ffff8800bdddb000
[    3.264743] software IO TLB at phys 0xb9ddb000 - 0xbdddb000

You can see here that the Software iotlb is left enabled. This is
where AMD IOMMU driver detects devices iommu can't handle and leaves
swiotlb enabled even after it initialized iommu.

[    3.265516] perf: AMD IBS detected (0x000000ff)
[    3.265731] audit: initializing netlink socket (disabled)
[    3.265742] type=2000 audit(1357265243.260:1): initialized
[    3.321516] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    3.399052] VFS: Disk quotas dquot_6.5.2

Please see attached dmesg for full log. I can do some testing on this
system with your patch if you would like.

-- Shuah

Attachment: dmesg.log
Description: Binary data