From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48B57C43331 for ; Tue, 12 Nov 2019 09:09:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F13E206B6 for ; Tue, 12 Nov 2019 09:09:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="dIMZSpm2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725944AbfKLJJT (ORCPT ); Tue, 12 Nov 2019 04:09:19 -0500 Received: from mail-ot1-f65.google.com ([209.85.210.65]:39818 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbfKLJJT (ORCPT ); Tue, 12 Nov 2019 04:09:19 -0500 Received: by mail-ot1-f65.google.com with SMTP id z9so536884otq.6 for ; Tue, 12 Nov 2019 01:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oHPKlhKO7XCkjzMpQFqzFclixAEBxx1FP1Cib9aUIt0=; b=dIMZSpm21n4Lvj7LNSVE3iXH8GIQCXuc3mlVLSXlQsySgf7fipjpWs11JR1/RPRcI9 N/Ip5mFgfWkRU+kPigYweaN9SrtcqiGMLihWrALL4n4IKxnX0Ct+UuZV1ML5Xg6T3wwf 5jcjaq2dc6AUDFu+sgoabnCxikipL9632C0Y8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oHPKlhKO7XCkjzMpQFqzFclixAEBxx1FP1Cib9aUIt0=; b=AGD12lNiUiQilQYURzBxRJIWSr+CW9JBujSdtu0UMrMsK+sxzcpzpuyUclP8E4jPV+ ymeZpK6cxHflgpEYoJBba8XAOgsOk3Byz0HuAtHlfvG40LgEMJvlh02eKGCXnwEAgniI y2LMctYmR5pfscYFYjkr5fEZ4tdkj3sQ5QI76hdv+LSIp2Ri0VZSTbs1LLj+nOzb5nYs TeEQaup9h7WApsGcTMkhpHlqsaWLR3IloY7eFwxN1EermnJ+df6USBRdoSmB71qNCvaX mKYDmSnnD2KR9n55QsVJEPGyZhYkouPwARvc0cG/b+pbhp+BGg46NzBGexJIrNb9n8D8 Ptyg== X-Gm-Message-State: APjAAAU++IR9C0+TSBPlDa+INc4pSLayEib+HG4Tb6wnK5dSh1myW/vD RBidk3CvU1HwHGPvjyHJzQ0OsfMcT+c7CAB2N3kqoA== X-Google-Smtp-Source: APXvYqxWSUfmQNdvctBvqvm85EKWYdHBsiXYTCfi0ftmMPCvgtA2sF1Cv5gyecUpE0AbnZ8p5aLaaGfCRxKiYiPvMQo= X-Received: by 2002:a9d:6649:: with SMTP id q9mr8533283otm.106.1573549758145; Tue, 12 Nov 2019 01:09:18 -0800 (PST) MIME-Version: 1.0 References: <20190718145407.21352-1-chris@chris-wilson.co.uk> <20190718145407.21352-4-chris@chris-wilson.co.uk> In-Reply-To: <20190718145407.21352-4-chris@chris-wilson.co.uk> From: Daniel Vetter Date: Tue, 12 Nov 2019 10:09:06 +0100 Message-ID: Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Flush stale cachelines on set-cache-level To: Chris Wilson , Joonas Lahtinen , Francisco Jerez Cc: intel-gfx , stable Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Thu, Jul 18, 2019 at 4:54 PM Chris Wilson wrote: > > Ensure that we flush any cache dirt out to main memory before the user > changes the cache-level as they may elect to bypass the cache (even after > declaring their access cache-coherent) via use of unprivileged MOCS. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: stable@vger.kernel.org > --- > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c > index 2e3ce2a69653..5d41e769a428 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c > @@ -277,6 +277,11 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj, > > list_for_each_entry(vma, &obj->vma.list, obj_link) > vma->node.color = cache_level; > + > + /* Flush any previous cache dirt in case of cache bypass */ > + if (obj->cache_dirty & ~obj->cache_coherent) > + i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC); I think writing out the bit logic instead of implicitly relying on the #defines would be much better, i.e. && !(cache_coherent & COHERENT_FOR_READ). Plus I think we only need to set cache_dirty = true if we don't flush here already, to avoid double flushing? -Daniel > + > i915_gem_object_set_cache_coherency(obj, cache_level); > obj->cache_dirty = true; /* Always invalidate stale cachelines */ > > -- > 2.22.0 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Flush stale cachelines on set-cache-level Date: Tue, 12 Nov 2019 10:09:06 +0100 Message-ID: References: <20190718145407.21352-1-chris@chris-wilson.co.uk> <20190718145407.21352-4-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190718145407.21352-4-chris@chris-wilson.co.uk> Sender: stable-owner@vger.kernel.org To: Chris Wilson , Joonas Lahtinen , Francisco Jerez Cc: intel-gfx , stable List-Id: intel-gfx@lists.freedesktop.org On Thu, Jul 18, 2019 at 4:54 PM Chris Wilson wrote: > > Ensure that we flush any cache dirt out to main memory before the user > changes the cache-level as they may elect to bypass the cache (even after > declaring their access cache-coherent) via use of unprivileged MOCS. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: stable@vger.kernel.org > --- > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c > index 2e3ce2a69653..5d41e769a428 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c > @@ -277,6 +277,11 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj, > > list_for_each_entry(vma, &obj->vma.list, obj_link) > vma->node.color = cache_level; > + > + /* Flush any previous cache dirt in case of cache bypass */ > + if (obj->cache_dirty & ~obj->cache_coherent) > + i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC); I think writing out the bit logic instead of implicitly relying on the #defines would be much better, i.e. && !(cache_coherent & COHERENT_FOR_READ). Plus I think we only need to set cache_dirty = true if we don't flush here already, to avoid double flushing? -Daniel > + > i915_gem_object_set_cache_coherency(obj, cache_level); > obj->cache_dirty = true; /* Always invalidate stale cachelines */ > > -- > 2.22.0 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA77FC17440 for ; Tue, 12 Nov 2019 09:09:20 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C1E9920674 for ; Tue, 12 Nov 2019 09:09:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C1E9920674 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5C78C6EA88; Tue, 12 Nov 2019 09:09:20 +0000 (UTC) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5628C6EA8D for ; Tue, 12 Nov 2019 09:09:19 +0000 (UTC) Received: by mail-ot1-x344.google.com with SMTP id 94so13681603oty.8 for ; Tue, 12 Nov 2019 01:09:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oHPKlhKO7XCkjzMpQFqzFclixAEBxx1FP1Cib9aUIt0=; b=FcRk+geMYJl13RBo6MjIDNJW47c4tWcx9nmj9qqFezF1mtClxvQnVHUh/0jYPhIqYF xCkTuTY7uQHdGQE4nYdz0rzfDltulx3vqzzLMVJoeDINC87jCD6y2fkNmKqAmHMBjhpn 39iw7lm2Rl9nNWepasXxA1WQ76Jb7nPRo2586bpDYGoadnXyEsSepudGcXhNTJeQAxfM zwssNNtz5jUWUAE2tyTwyn5lUKKuQj4BO2xpouQ815sVqtWTCnDQVQVI1ezZI1RfzSDq KmO1vZ31tyQ/EWydCugmk60ZDoaCAlevw2ono9hZK8FPuRSCV9ozXpucLO1Sm912G3F5 QXrw== X-Gm-Message-State: APjAAAXYCEWGFrAJ5RM67gSoJJDKTsykWm1m0eZUyWKIYHZftDMtEe+V ylt+wv771sMO/vpPAMieIxr5TTqUfiD/6LSf9ZRYhA== X-Google-Smtp-Source: APXvYqxWSUfmQNdvctBvqvm85EKWYdHBsiXYTCfi0ftmMPCvgtA2sF1Cv5gyecUpE0AbnZ8p5aLaaGfCRxKiYiPvMQo= X-Received: by 2002:a9d:6649:: with SMTP id q9mr8533283otm.106.1573549758145; Tue, 12 Nov 2019 01:09:18 -0800 (PST) MIME-Version: 1.0 References: <20190718145407.21352-1-chris@chris-wilson.co.uk> <20190718145407.21352-4-chris@chris-wilson.co.uk> In-Reply-To: <20190718145407.21352-4-chris@chris-wilson.co.uk> From: Daniel Vetter Date: Tue, 12 Nov 2019 10:09:06 +0100 Message-ID: To: Chris Wilson , Joonas Lahtinen , Francisco Jerez X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oHPKlhKO7XCkjzMpQFqzFclixAEBxx1FP1Cib9aUIt0=; b=dIMZSpm21n4Lvj7LNSVE3iXH8GIQCXuc3mlVLSXlQsySgf7fipjpWs11JR1/RPRcI9 N/Ip5mFgfWkRU+kPigYweaN9SrtcqiGMLihWrALL4n4IKxnX0Ct+UuZV1ML5Xg6T3wwf 5jcjaq2dc6AUDFu+sgoabnCxikipL9632C0Y8= Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Flush stale cachelines on set-cache-level X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx , stable Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Message-ID: <20191112090906.o0f8wbSVZzOHy49-QFcZYKHliTMSgIxAg2oHeH-JfNE@z> T24gVGh1LCBKdWwgMTgsIDIwMTkgYXQgNDo1NCBQTSBDaHJpcyBXaWxzb24gPGNocmlzQGNocmlz LXdpbHNvbi5jby51az4gd3JvdGU6Cj4KPiBFbnN1cmUgdGhhdCB3ZSBmbHVzaCBhbnkgY2FjaGUg ZGlydCBvdXQgdG8gbWFpbiBtZW1vcnkgYmVmb3JlIHRoZSB1c2VyCj4gY2hhbmdlcyB0aGUgY2Fj aGUtbGV2ZWwgYXMgdGhleSBtYXkgZWxlY3QgdG8gYnlwYXNzIHRoZSBjYWNoZSAoZXZlbiBhZnRl cgo+IGRlY2xhcmluZyB0aGVpciBhY2Nlc3MgY2FjaGUtY29oZXJlbnQpIHZpYSB1c2Ugb2YgdW5w cml2aWxlZ2VkIE1PQ1MuCj4KPiBTaWduZWQtb2ZmLWJ5OiBDaHJpcyBXaWxzb24gPGNocmlzQGNo cmlzLXdpbHNvbi5jby51az4KPiBDYzogSm9vbmFzIExhaHRpbmVuIDxqb29uYXMubGFodGluZW5A bGludXguaW50ZWwuY29tPgo+IENjOiBzdGFibGVAdmdlci5rZXJuZWwub3JnCj4gLS0tCj4gIGRy aXZlcnMvZ3B1L2RybS9pOTE1L2dlbS9pOTE1X2dlbV9kb21haW4uYyB8IDUgKysrKysKPiAgMSBm aWxlIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKQo+Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvZ3B1 L2RybS9pOTE1L2dlbS9pOTE1X2dlbV9kb21haW4uYyBiL2RyaXZlcnMvZ3B1L2RybS9pOTE1L2dl bS9pOTE1X2dlbV9kb21haW4uYwo+IGluZGV4IDJlM2NlMmE2OTY1My4uNWQ0MWU3NjlhNDI4IDEw MDY0NAo+IC0tLSBhL2RyaXZlcnMvZ3B1L2RybS9pOTE1L2dlbS9pOTE1X2dlbV9kb21haW4uYwo+ ICsrKyBiL2RyaXZlcnMvZ3B1L2RybS9pOTE1L2dlbS9pOTE1X2dlbV9kb21haW4uYwo+IEBAIC0y NzcsNiArMjc3LDExIEBAIGludCBpOTE1X2dlbV9vYmplY3Rfc2V0X2NhY2hlX2xldmVsKHN0cnVj dCBkcm1faTkxNV9nZW1fb2JqZWN0ICpvYmosCj4KPiAgICAgICAgIGxpc3RfZm9yX2VhY2hfZW50 cnkodm1hLCAmb2JqLT52bWEubGlzdCwgb2JqX2xpbmspCj4gICAgICAgICAgICAgICAgIHZtYS0+ bm9kZS5jb2xvciA9IGNhY2hlX2xldmVsOwo+ICsKPiArICAgICAgIC8qIEZsdXNoIGFueSBwcmV2 aW91cyBjYWNoZSBkaXJ0IGluIGNhc2Ugb2YgY2FjaGUgYnlwYXNzICovCj4gKyAgICAgICBpZiAo b2JqLT5jYWNoZV9kaXJ0eSAmIH5vYmotPmNhY2hlX2NvaGVyZW50KQo+ICsgICAgICAgICAgICAg ICBpOTE1X2dlbV9jbGZsdXNoX29iamVjdChvYmosIEk5MTVfQ0xGTFVTSF9TWU5DKTsKCkkgdGhp bmsgd3JpdGluZyBvdXQgdGhlIGJpdCBsb2dpYyBpbnN0ZWFkIG9mIGltcGxpY2l0bHkgcmVseWlu ZyBvbiB0aGUKI2RlZmluZXMgd291bGQgYmUgbXVjaCBiZXR0ZXIsIGkuZS4gJiYgIShjYWNoZV9j b2hlcmVudCAmCkNPSEVSRU5UX0ZPUl9SRUFEKS4gUGx1cyBJIHRoaW5rIHdlIG9ubHkgbmVlZCB0 byBzZXQgY2FjaGVfZGlydHkgPQp0cnVlIGlmIHdlIGRvbid0IGZsdXNoIGhlcmUgYWxyZWFkeSwg dG8gYXZvaWQgZG91YmxlIGZsdXNoaW5nPwotRGFuaWVsCgo+ICsKPiAgICAgICAgIGk5MTVfZ2Vt X29iamVjdF9zZXRfY2FjaGVfY29oZXJlbmN5KG9iaiwgY2FjaGVfbGV2ZWwpOwo+ICAgICAgICAg b2JqLT5jYWNoZV9kaXJ0eSA9IHRydWU7IC8qIEFsd2F5cyBpbnZhbGlkYXRlIHN0YWxlIGNhY2hl bGluZXMgKi8KPgo+IC0tCj4gMi4yMi4wCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+IEludGVsLWdmeCBtYWlsaW5nIGxpc3QKPiBJbnRlbC1nZnhA bGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFp bG1hbi9saXN0aW5mby9pbnRlbC1nZngKCgoKLS0KRGFuaWVsIFZldHRlcgpTb2Z0d2FyZSBFbmdp bmVlciwgSW50ZWwgQ29ycG9yYXRpb24KKzQxICgwKSA3OSAzNjUgNTcgNDggLSBodHRwOi8vYmxv Zy5mZndsbC5jaApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpJbnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVsLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcK aHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZng=