On 4/15/2025 11:58 PM, Alejandro Jimenez wrote:
On 4/15/25 2:38 AM, Sairaj Kodilkar wrote:
Hi Alejandro,
On 4/15/2025 1:56 AM, Alejandro Jimenez wrote:
Hi Sairaj,
I'm conflicted by the implementation of the change, so I'd like to
make sure I fully understand...
On 4/10/25 2:44 AM,
On 4/15/25 2:38 AM, Sairaj Kodilkar wrote:
Hi Alejandro,
On 4/15/2025 1:56 AM, Alejandro Jimenez wrote:
Hi Sairaj,
I'm conflicted by the implementation of the change, so I'd like to
make sure I fully understand...
On 4/10/25 2:44 AM, Sairaj Kodilkar wrote:
Fix the issue by removing
Hi Alejandro,
On 4/15/2025 1:56 AM, Alejandro Jimenez wrote:
Hi Sairaj,
I'm conflicted by the implementation of the change, so I'd like to make
sure I fully understand...
On 4/10/25 2:44 AM, Sairaj Kodilkar wrote:
Current amd_iommu enables the iommu_nodma address space when pt_supported
Hi Sairaj,
I'm conflicted by the implementation of the change, so I'd like to make
sure I fully understand...
On 4/10/25 2:44 AM, Sairaj Kodilkar wrote:
Current amd_iommu enables the iommu_nodma address space when pt_supported
flag is on.
As it should, that is the intended purpose of the i
+ Michael,
On 4/10/2025 12:14 PM, Sairaj Kodilkar wrote:
> Current amd_iommu enables the iommu_nodma address space when pt_supported
> flag is on. This causes device to bypass the IOMMU and use untranslated
> address to perform DMA when guest kernel uses DMA mode, resulting in
> failure to setup
Current amd_iommu enables the iommu_nodma address space when pt_supported
flag is on. This causes device to bypass the IOMMU and use untranslated
address to perform DMA when guest kernel uses DMA mode, resulting in
failure to setup the devices in the guest.
Fix the issue by removing pt_supported c
