On to, 2017-04-27 at 05:54 +0000, Zhang, Xiong Y wrote: > > > > Also, was fixing the IGD driver loading with zero stolen memory > > considered instead? All this information should exist in the commit > > message. > [Zhang, Xiong Y] IGD and i915 driver read pci config register 0x50 to get > the size of stolen memory. When guest read this register, qemu could trap > it and return one value to guest. > So in order to " fixing the IGD driver loading with zero stolen memory ", > We have to modify both Qemu and IGD driver: > 1) QEMU: trap read from pci cfg 0x50 register, then return zero to guest > 2) IGD driver: when IGD driver see zero size of stolen memory, don't exit loading > and continue. > This doesn't give any benefit to i915, i915 will still disable stolen memory as i915 > see zero size stolen memory . So I prefer to disable stolen memory in i915 directly > and keep Qemu and IGD driver unchanged. If due to lack of code in QEMU, RMRR is not available. It'd sound to me they should carry the change to report stolen as zero, because they're in best position to track if that changes in future. Also, if the IGD driver requires a special treatment where stolen is reported to exist but is not functional, that logic should be fixed where the flaw is. i915 driver is not the go-to for fixing any quirks and lack of code related to virtualization. The driver performs perfectly logically, if stolen is reported to exist, it is expected to work, if not, it's not touched. Adding special cases to satisfy conditions outside of i915 will make driver maintenance a burden. And, if all other options fail and we end up having to fix the issue in i915, the fix should be robust, which this currently is not (see my previous messages). 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
