+ David and Jon On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote: The blocking issue I see is that bisecting is still not pointing at relevant commits. Both bisected commits from Bugzilla are not related to changes in stolen memory usage behavior. I'd assume a successful bisect to land at the patches where we start creating kernel internal objects from stolen memory. Otherwise we could be ignoring a bug elsewhere. If it consistently lands on those patches, then there might be something wrong with them, in addition to stolen memory problems. Disabling power saving makes many bugs go away, but we still don't disable power saving as a resolution to such bugs, but instead root cause and fix the individual bugs. > Stolen memory isn't a standard pci resource and exists in RMRR which has > identity mapping in iommu table when host boot up, so IGD could access > stolen memory in host OS. While according to 'commit c875d2c1b808 > ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains")',RMRR > isn't supported by kvm, then both EPT and guest iommu domain table lack > of maaping for stolen memory in kvm IGD passthrough environment. Commit message text still fails to address that an exclusion was added by commit: commit 18436afdc11a00ac881990b454cfb2eae81d6003 Author: David Woodhouse <David.Woodhouse@xxxxxxxxx> Date: Wed Mar 25 15:05:47 2015 +0000 iommu/vt-d: Allow RMRR on graphics devices too Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains") prevents certain options for devices with RMRRs. This even prevents those devices from getting a 1:1 mapping with 'iommu=pt', because we don't have the code to handle *preserving* the RMRR regions when moving the device between domains. <SNIP> The quoted part of David's commit message leads me to believe it's simply lack of some code in kernel for juggling the RMRRs when moving a device between domains that is missing. Why is not that considered instead? With that implemented, we would have more transparent pass- through, which should be good. Also, was fixing the IGD driver loading with zero stolen memory considered instead? All this information should exist in the commit message. After the bisecting is properly done, there is an agreement that suggested RMRR preservation is absolutely a no-go, other options are not viable, the commit message should be updated to reflect all that. Then we should look in more detail on how to detect the scenarios when we're running in a virtual machine that doesn't set up the 1:1 mapping for RMRRs. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation