+ 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
