> From: Joonas Lahtinen [mailto:joonas.lahtinen@xxxxxxxxxxxxxxx] > Sent: Wednesday, April 12, 2017 9:22 PM > [...] > By my limited understanding of VT-d details: The stolen memory is never > directly accessed by i915 driver (because CPU access doesn't work even > in DOM0). It is only used through the aperture, which just requires for > the GT device to have access to the RMRR. Further, the GT device needs > to have access to stolen memory, because that's what GuC uses for > backing storage for for WOPCM. > > And even if after all of the above is addressed, shouldn't we rather > try to detect the lack of RMRR, than presence of QEMU ISA? > > What comes to my mind is exporting function like device_has_rmrr() from > intel-iommu.com and consuming that, if we end up doing this. That way, > if somebody, some day, goes and write RMRR pass-through code currently > missing, it'll start working, just like it should. > I like what you proposed in the long run, e.g. in a nested virtualization environment L0-VMM assigns the device to L1-VMM which further wants to assign device to L2-VM. In such case RMRR information must be propagated through the path to L1-VMM. However I can see one limitation here on your proposal. There is no RMRR if VT-d is disabled in BIOS. Then you cannot use stolen memory even on bare metal in such configuration, which is possibly not desired. Also the long term direction is to move away from RMRR for Intel integrated devices. People realized its limitation (especially the objection from KVM community. I don't think RMRR passthrough would be an option there). So I'd be with Xiong's simple workaround here. :-) Thanks Kevin