Re: [bug report] iommu/vt-d: Fix unmap_pages support

Hi Dan. The updated patch has landed in mainline, as per : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86dc40c7ea9c22f64571e0e45f695de73a0e2644 On Mon, Nov 29, 2021 at 2:00 PM Dan Carpenter wrote: > > Hello Alex Williamson, > > The patch edad96db58d2:

Re: [PATCH] iommu/vt-d: Fix unmap_pages support

_pte_clear_level() is assumed to clear to the end of the > level pte page, then our next pfn should be calculated from level_pfn > rather than our working pfn. > > Fixes: 3f34f1259776 ("iommu/vt-d: Implement map/unmap_pages() iommu_ops > callback") > Reported-by: Aj

Re: [PATCH v2] iommu: intel: do deep dma-unmapping, to avoid kernel-flooding.

CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ > AERCap:First Error Pointer: 00, ECRCGenCap- ECRCGenEn- > ECRCChkCap- ECRCChkEn- > MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- > HeaderLog: >

Re: [PATCH v2] iommu: intel: do deep dma-unmapping, to avoid kernel-flooding.

race. > > iii) > Step ii) runs in abundance, and the kernel-logs run insane. > > > > === Fix === > > We ensure that as part of a dma-unmapping, each (unmapped) pte-slot > is also cleared of its value/content (at the leaf-level, where the > real mapping from a i

Re: Host-PCI-Device mapping

Never mind, found the answers in kvm_set_user_memory :) On Fri, Oct 15, 2021 at 9:36 PM Ajay Garg wrote: > > Hello everyone. > > I have a x86_64 L1 guest, running on a x86_64 host, with a > host-pci-device attached to the guest. > The host runs with IOMMU enabled, and p

Host-PCI-Device mapping

Hello everyone. I have a x86_64 L1 guest, running on a x86_64 host, with a host-pci-device attached to the guest. The host runs with IOMMU enabled, and passthrough enabled. Following are the addresses of the bar0-region of the pci-device, as per the output of lspci -v : * On host (hpa) =>

Re: [PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.

Hi Alex, Lu. Posted v2 patch, as per https://lists.linuxfoundation.org/pipermail/iommu/2021-October/059955.html Kindly review, and let's continue on that thread now. Thanks and Regards, Ajay On Mon, Oct 11, 2021 at 11:43 PM Ajay Garg wrote: > > Thanks Alex for your time. > > I

[PATCH v2] iommu: intel: do deep dma-unmapping, to avoid kernel-flooding.

g. Signed-off-by: Ajay Garg --- drivers/iommu/intel/iommu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index d75f59ae28e6..485a8ea71394 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -5090,6 +

Re: [PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.

Thanks Alex for your time. I think I may have found the issue. Right now, when doing a dma-unmapping, we do a "soft-unmapping" only, as the pte-values themselves are not cleared in the unlinked pagetable-frame. I have made the (simple) changes, and things are looking good as of now (almost an

Re: [PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.

The flooding was seen today again, after I booted the host-machine in the morning. Need to look what the heck is going on ... On Sun, Oct 10, 2021 at 11:45 AM Ajay Garg wrote: > > > I'll try and backtrack to the userspace process that is sending these > > ioctls. > > >

Re: [PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.

> I'll try and backtrack to the userspace process that is sending these ioctls. > The userspace process is qemu. I compiled qemu from latest source, installed via "sudo make install" on host-machine, rebooted the host-machine, and booted up the guest-machine on the host-machine. Now, no

Re: [PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.

sending these ioctls. Thanks and Regards, Ajay On Tue, Oct 5, 2021 at 4:01 AM Alex Williamson wrote: > > On Sat, 2 Oct 2021 22:48:24 +0530 > Ajay Garg wrote: > > > Thanks Lu for the reply. > > > > > > > > Isn't the domain should be switched from a

Fitment/Use of IOMMU in KVM world when using PCI-devices

Hi All. I have been learning about a lot of inter-related things, kindly correct me if I am wrong anywhere. Till now, following have been broad observations : a) If we have IOMMU disabled on the host, things work fine in general on a guest. But we cannot a attach a pci-device (physically

Re: [PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.

Thanks Lu for the reply. > > Isn't the domain should be switched from a default domain to an > unmanaged domain when the device is assigned to the guest? > > Even you want to r-setup the same mappings, you need to un-map all > existing mappings, right? > Hmm, I guess that's a (design) decision

[PATCH] iommu: intel: remove flooding of non-error logs, when new-DMA-PTE is the same as old-DMA-PTE.

. Signed-off-by: Ajay Garg --- drivers/iommu/intel/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index d75f59ae28e6..8bea8b4e3ff9 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c

Upstream-Patching for iommu (intel)

Hi All. What is the upstream list, wherein patches for iommu (intel) might be posted? Is it iommu@lists.linux-foundation.org? Thanks and Regards, Ajay ___ iommu mailing list iommu@lists.linux-foundation.org