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 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F0320C88E77 for ; Wed, 16 Sep 2026 13:43:36 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1423164.1648421 (Exim 4.92) (envelope-from ) id 1x6puh-0005OQ-Oa; Wed, 16 Sep 2026 13:43:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1423164.1648421; Wed, 16 Sep 2026 13:43:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6puh-0005OJ-La; Wed, 16 Sep 2026 13:43:03 +0000 Received: by outflank-mailman (input) for mailman id 1423164; Wed, 16 Sep 2026 13:43:02 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x6pug-0005OD-1c for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 13:43:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x6pue-00GuGo-Hn for xen-devel@lists.xenproject.org; Wed, 16 Sep 2026 15:43:01 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6aaa9ce1-8faa-0a2a0a5109dd-0a2a45019bfa-4 for ; Wed, 16 Sep 2026 15:42:59 +0200 Received: from [198.175.65.14] (helo=mgamail.intel.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6aaa9ce0-5984-0a2a45010019-c6af410e65d3-3 for ; Wed, 16 Sep 2026 15:42:58 +0200 Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2026 06:42:56 -0700 Received: from conormcd-mobl2.ger.corp.intel.com (HELO [10.245.244.154]) ([10.245.244.154]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2026 06:42:55 -0700 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=Intel header.d=intel.com header.i="@intel.com" header.h="Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Transfer-Encoding:MIME-Version" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1789566178; x=1821102178; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=lMOHGhqhRC7o8DUWxe2ZtG0eCBNNwQPKpwZSpxZkLjE=; b=E3WHzNVf+vIl6B6suA0kI16gdSsDKTtBZkOdYMxEA77ihaJXfUR6jB5g mGToMpf9INx8Of7hId02n1lnzz0rDh8vgKkbBjFkYMIs4N590vgb7iNA0 Zl66OCSz4wODHPndKHXROXSCuQxVaRyJPpUgy//LZfhTM4IihWbpPGcL4 j+FjjGXVkx6+2Qi+0P5GIvmTCxdc+6LTKgQqG09zhrfYaGlVDma1hyPin HXJJz9As0TH/Y+3y5Jc0OrLjJ75Z5v4sJwkTJ+yQH49tuqUyNhquHjbu0 iuTsZkDpQP/CMeCs2Q0NIYgZMRz3BfO7GC2gwcXyL2SxbOGsfw0F6h0CN Q==; X-CSE-ConnectionGUID: tmjk79AISji5MdGEoqYUkw== X-CSE-MsgGUID: 6TQlCiFrTOG8VCKq2euD1A== X-IronPort-AV: E=McAfee;i="6800,10657,11905"; a="93814093" X-IronPort-AV: E=Sophos;i="6.27,103,1787036400"; d="scan'208";a="93814093" X-CSE-ConnectionGUID: 33c8L43rQM+N7DHUEOWbWA== X-CSE-MsgGUID: IuQaeLKrSrK4WNC52PKSyQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,103,1787036400"; d="scan'208";a="303230461" Message-ID: <2efce17e1036dae156f0eb3f8abbce98e754d537.camel@linux.intel.com> Subject: Re: [PATCH] drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Szymon =?UTF-8?Q?Aceda=C5=84ski?= , intel-xe@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org, marmarek@invisiblethingslab.com, xen-devel@lists.xenproject.org, stable@vger.kernel.org Date: Wed, 16 Sep 2026 15:42:52 +0200 In-Reply-To: <20260820101212.1608543-1-accek@invisiblethingslab.com> References: <20260820101212.1608543-1-accek@invisiblethingslab.com> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) MIME-Version: 1.0 X-purgate-ID: tlsNG-d62444/1789566179-BFC69757-49853FCB/0/0 X-purgate-type: clean X-purgate-size: 3099 Hi! On Thu, 2026-08-20 at 12:12 +0200, Szymon Aceda=C5=84ski wrote: > Fixes display corruption on Xen PV dom0, where DMA buffers are not Please use imperative language in commit messages: "Fix display corruption..." > guaranteed machine-contiguous, in which case bounce buffering kicks > in, breaking xe's memory coherency assumptions. >=20 > Apply the same workaround i915 carries in i915_sg_segment_size() > since > commit 78a07fe777c4 ("drm/i915: stop abusing swiotlb_max_segment"). >=20 > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel > GPUs") > Reported-by: Marek Marczykowski-G=C3=B3recki > > Closes: > https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8382 > Link: https://lore.kernel.org/xen-devel/aYtznP_tT6xNPwf-@mail-itl/ > Link: > https://lore.kernel.org/all/20221020110308.1582518-1-hch@lst.de/=C2=A0# > i915 counterpart > Cc: stable@vger.kernel.org=C2=A0# v6.8+ > Signed-off-by: Szymon Aceda=C5=84ski Please also CC the Author of the original i915 patch in case there are any updates to the validity of this hack. While there is a precedent in i915 authored by Christoph, the patch really relies on completely undocumented behaviour.... Otherwise LGTM, Once you have an update I'll forward it to Xe CI. Thanks, Thomas > --- > =C2=A0drivers/gpu/drm/xe/xe_bo.h | 19 +++++++++++++++++++ > =C2=A01 file changed, 19 insertions(+) >=20 > diff --git a/drivers/gpu/drm/xe/xe_bo.h b/drivers/gpu/drm/xe/xe_bo.h > index e8081af..152bfcf 100644 > --- a/drivers/gpu/drm/xe/xe_bo.h > +++ b/drivers/gpu/drm/xe/xe_bo.h > @@ -9,6 +9,8 @@ > =C2=A0#include > =C2=A0#include > =C2=A0 > +#include > + > =C2=A0#include "xe_bo_types.h" > =C2=A0#include "xe_ggtt.h" > =C2=A0#include "xe_macros.h" > @@ -575,6 +577,23 @@ static inline unsigned int > xe_sg_segment_size(struct device *dev) > =C2=A0 struct scatterlist __maybe_unused sg; > =C2=A0 size_t max =3D BIT_ULL(sizeof(sg.length) * 8) - 1; > =C2=A0 > + /* > + * For Xen PV guests pages aren't contiguous in DMA > (machine) address > + * space.=C2=A0 The DMA API takes care of that both in > dma_alloc_* (by > + * calling into the hypervisor to make the pages contiguous) > and in > + * dma_map_* (by bounce buffering).=C2=A0 But xe (like i915, see > commit > + * 78a07fe777c4) ignores the coherency aspects of the DMA > API and thus > + * can't cope with bounce buffering actually happening, so > add a hack > + * here to force small allocations and mappings when running > in PV > + * mode on Xen. > + * > + * Note this will still break if bounce buffering is > required for other > + * reasons, like confidential computing hypervisors or PCIe > root ports > + * with addressing limitations. > + */ > + if (xen_pv_domain()) > + return PAGE_SIZE; > + > =C2=A0 max =3D min_t(size_t, max, dma_max_mapping_size(dev)); > =C2=A0 > =C2=A0 /* >=20 > base-commit: b4f95affc66ef76342c1f6bf3849f6c8ade6b9d6