From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joonas Lahtinen Subject: Re: [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm Date: Tue, 25 Apr 2017 15:06:43 +0300 Message-ID: <1493122003.3731.27.camel@linux.intel.com> References: <1493116501-29327-1-git-send-email-xiong.y.zhang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1493116501-29327-1-git-send-email-xiong.y.zhang@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Xiong Zhang , kevin.tian@intel.com, daniel.vetter@intel.com, zhenyuw@linux.intel.com, jani.nikula@linux.intel.com, alex.williamson@redhat.com, David Woodhouse , "Bloomfield, Jon" Cc: intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, stable@vger.kernel.org List-Id: intel-gfx@lists.freedesktop.org KyBEYXZpZCBhbmQgSm9uCgpPbiB0aSwgMjAxNy0wNC0yNSBhdCAxODozNCArMDgwMCwgWGlvbmcg Wmhhbmcgd3JvdGU6CgpUaGUgYmxvY2tpbmcgaXNzdWUgSSBzZWUgaXMgdGhhdCBiaXNlY3Rpbmcg aXMgc3RpbGwgbm90IHBvaW50aW5nIGF0CnJlbGV2YW50IGNvbW1pdHMuIEJvdGggYmlzZWN0ZWQg Y29tbWl0cyBmcm9tIEJ1Z3ppbGxhIGFyZSBub3QgcmVsYXRlZAp0byBjaGFuZ2VzIGluIHN0b2xl biBtZW1vcnkgdXNhZ2UgYmVoYXZpb3IuIEknZCBhc3N1bWUgYSBzdWNjZXNzZnVsCmJpc2VjdCB0 byBsYW5kIGF0IHRoZSBwYXRjaGVzIHdoZXJlIHdlIHN0YXJ0IGNyZWF0aW5nIGtlcm5lbCBpbnRl cm5hbApvYmplY3RzIGZyb20gc3RvbGVuIG1lbW9yeS4gT3RoZXJ3aXNlIHdlIGNvdWxkIGJlIGln bm9yaW5nIGEgYnVnCmVsc2V3aGVyZS4gSWYgaXQgY29uc2lzdGVudGx5IGxhbmRzIG9uIHRob3Nl IHBhdGNoZXMsIHRoZW4gdGhlcmUgbWlnaHQKYmUgc29tZXRoaW5nIHdyb25nIHdpdGggdGhlbSwg aW4gYWRkaXRpb24gdG8gc3RvbGVuIG1lbW9yeSBwcm9ibGVtcy4KCkRpc2FibGluZyBwb3dlciBz YXZpbmcgbWFrZXMgbWFueSBidWdzIGdvIGF3YXksIGJ1dCB3ZSBzdGlsbCBkb24ndApkaXNhYmxl IHBvd2VyIHNhdmluZyBhcyBhIHJlc29sdXRpb24gdG8gc3VjaCBidWdzLCBidXQgaW5zdGVhZCBy b290CmNhdXNlIGFuZCBmaXggdGhlIGluZGl2aWR1YWwgYnVncy4KCj4gU3RvbGVuIG1lbW9yeSBp c24ndCBhIHN0YW5kYXJkIHBjaSByZXNvdXJjZSBhbmQgZXhpc3RzIGluIFJNUlIgd2hpY2ggaGFz Cj4gaWRlbnRpdHkgbWFwcGluZyBpbiBpb21tdSB0YWJsZSB3aGVuIGhvc3QgYm9vdCB1cCwgc28g SUdEIGNvdWxkIGFjY2Vzcwo+IHN0b2xlbiBtZW1vcnkgaW4gaG9zdCBPUy4gV2hpbGUgYWNjb3Jk aW5nIHRvICdjb21taXQgYzg3NWQyYzFiODA4Cj4gKCJpb21tdS92dC1kOiBFeGNsdWRlIGRldmlj ZXMgdXNpbmcgUk1SUnMgZnJvbSBJT01NVSBBUEkgZG9tYWlucyIpJyxSTVJSCj4gaXNuJ3Qgc3Vw cG9ydGVkIGJ5IGt2bSwgdGhlbiBib3RoIEVQVCBhbmQgZ3Vlc3QgaW9tbXUgZG9tYWluIHRhYmxl IGxhY2sKPiBvZiBtYWFwaW5nIGZvciBzdG9sZW4gbWVtb3J5IGluIGt2bSBJR0QgcGFzc3Rocm91 Z2ggZW52aXJvbm1lbnQuCgpDb21taXQgbWVzc2FnZSB0ZXh0IHN0aWxsIGZhaWxzIHRvIGFkZHJl c3MgdGhhdCBhbiBleGNsdXNpb24gd2FzIGFkZGVkCmJ5IGNvbW1pdDoKCmNvbW1pdCAxODQzNmFm ZGMxMWEwMGFjODgxOTkwYjQ1NGNmYjJlYWU4MWQ2MDAzCkF1dGhvcjogRGF2aWQgV29vZGhvdXNl IDxEYXZpZC5Xb29kaG91c2VAaW50ZWwuY29tPgpEYXRlOsKgwqDCoFdlZCBNYXIgMjUgMTU6MDU6 NDcgMjAxNSArMDAwMAoKwqDCoMKgwqBpb21tdS92dC1kOiBBbGxvdyBSTVJSIG9uIGdyYXBoaWNz IGRldmljZXMgdG9vCgrCoCDCoCBDb21taXQgYzg3NWQyYzEgKCJpb21tdS92dC1kOiBFeGNsdWRl IGRldmljZXMgdXNpbmcgUk1SUnMgZnJvbSBJT01NVSBBUEkKwqDCoMKgwqBkb21haW5zIikgcHJl dmVudHMgY2VydGFpbiBvcHRpb25zIGZvciBkZXZpY2VzIHdpdGggUk1SUnMuIFRoaXMgZXZlbgrC oMKgwqDCoHByZXZlbnRzIHRob3NlIGRldmljZXMgZnJvbSBnZXR0aW5nIGEgMToxIG1hcHBpbmcg d2l0aCAnaW9tbXU9cHQnLArCoMKgwqDCoGJlY2F1c2Ugd2UgZG9uJ3QgaGF2ZSB0aGUgY29kZSB0 byBoYW5kbGUgKnByZXNlcnZpbmcqIHRoZSBSTVJSIHJlZ2lvbnMKwqDCoMKgwqB3aGVuIG1vdmlu ZyB0aGUgZGV2aWNlIGJldHdlZW4gZG9tYWlucy4KCjxTTklQPgoKVGhlIHF1b3RlZCBwYXJ0IG9m IERhdmlkJ3MgY29tbWl0IG1lc3NhZ2UgbGVhZHMgbWUgdG8gYmVsaWV2ZSBpdCdzCnNpbXBseSBs YWNrIG9mIHNvbWUgY29kZSBpbiBrZXJuZWwgZm9yIGp1Z2dsaW5nIHRoZSBSTVJScyB3aGVuIG1v dmluZyBhCmRldmljZSBiZXR3ZWVuIGRvbWFpbnMgdGhhdCBpcyBtaXNzaW5nLiBXaHkgaXMgbm90 IHRoYXQgY29uc2lkZXJlZAppbnN0ZWFkPyBXaXRoIHRoYXQgaW1wbGVtZW50ZWQsIHdlIHdvdWxk IGhhdmUgbW9yZSB0cmFuc3BhcmVudCBwYXNzLQp0aHJvdWdoLCB3aGljaCBzaG91bGQgYmUgZ29v ZC4KCkFsc28sIHdhcyBmaXhpbmcgdGhlIElHRCBkcml2ZXIgbG9hZGluZyB3aXRoIHplcm8gc3Rv bGVuIG1lbW9yeQpjb25zaWRlcmVkIGluc3RlYWQ/IEFsbCB0aGlzIGluZm9ybWF0aW9uIHNob3Vs ZCBleGlzdCBpbiB0aGUgY29tbWl0Cm1lc3NhZ2UuCgpBZnRlciB0aGUgYmlzZWN0aW5nIGlzIHBy b3Blcmx5IGRvbmUsIHRoZXJlIGlzIGFuIGFncmVlbWVudCB0aGF0CnN1Z2dlc3RlZCBSTVJSIHBy ZXNlcnZhdGlvbiBpcyBhYnNvbHV0ZWx5IGEgbm8tZ28sIG90aGVyIG9wdGlvbnMgYXJlCm5vdCB2 aWFibGUsIHRoZSBjb21taXQgbWVzc2FnZSBzaG91bGQgYmUgdXBkYXRlZCB0byByZWZsZWN0IGFs bCB0aGF0LgpUaGVuIHdlIHNob3VsZCBsb29rIGluIG1vcmUgZGV0YWlsIG9uIGhvdyB0byBkZXRl Y3QgdGhlIHNjZW5hcmlvcyB3aGVuCndlJ3JlIHJ1bm5pbmcgaW4gYSB2aXJ0dWFsIG1hY2hpbmUg dGhhdCBkb2Vzbid0IHNldCB1cCB0aGUgMToxIG1hcHBpbmcKZm9yIFJNUlJzLgoKUmVnYXJkcywg Sm9vbmFzCi0tIApKb29uYXMgTGFodGluZW4KT3BlbiBTb3VyY2UgVGVjaG5vbG9neSBDZW50ZXIK SW50ZWwgQ29ycG9yYXRpb24KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KSW50ZWwtZ2Z4IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0 b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50 ZWwtZ2Z4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com ([192.55.52.120]:45906 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1171284AbdDYMGt (ORCPT ); Tue, 25 Apr 2017 08:06:49 -0400 Message-ID: <1493122003.3731.27.camel@linux.intel.com> Subject: Re: [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm From: Joonas Lahtinen To: Xiong Zhang , kevin.tian@intel.com, daniel.vetter@intel.com, zhenyuw@linux.intel.com, jani.nikula@linux.intel.com, alex.williamson@redhat.com, David Woodhouse , "Bloomfield, Jon" Cc: intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, stable@vger.kernel.org Date: Tue, 25 Apr 2017 15:06:43 +0300 In-Reply-To: <1493116501-29327-1-git-send-email-xiong.y.zhang@intel.com> References: <1493116501-29327-1-git-send-email-xiong.y.zhang@intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: + 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 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. 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