From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail132-4.atl131.mandrillapp.com (mail132-4.atl131.mandrillapp.com [198.2.132.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99C473054EB for ; Tue, 6 Jan 2026 22:47:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.2.132.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767739642; cv=none; b=UCOAcMklz0jCo8TgL9h9LjXv6hsx9tKFGw7PNr24ruj6Ojvuvsd3ww5eO3T7lNAvy39Ht6Dx5pFciHs6VLk9qMQ++YBQ0mEatQTi5VKd117J4NZFaHP0KsSAXR0paOiLQ8gmCGiY7NK7X9MbAk4iKsRtT4Yu/TvT6VxNEGBtEB4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767739642; c=relaxed/simple; bh=EBESooK6XWn0vJQhbF/yJPdwfqy4J7FAIlVVdFMzoEM=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Date: MIME-Version:Content-Type; b=eeBFx5L0ABAq7iubjOxwwGBBRGFMRN3EEnJpETW9c6xIQJipvDV4snlAqSU6cbPjgWaghjGNXteDdipiy6zakzdxQl5YFt5OLlhiGsDIJ2iUGogrMhwvKL2wqeUYgJudY87/JV1BHcQXQak/tZsVLaUbp0U5qxyJRkz+3NWtzCo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=vates.tech; spf=pass smtp.mailfrom=bounce.vates.tech; dkim=pass (2048-bit key) header.d=mandrillapp.com header.i=@mandrillapp.com header.b=qj2CnuGh; dkim=pass (2048-bit key) header.d=vates.tech header.i=teddy.astie@vates.tech header.b=mOc/ycEf; arc=none smtp.client-ip=198.2.132.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=vates.tech Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bounce.vates.tech Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mandrillapp.com header.i=@mandrillapp.com header.b="qj2CnuGh"; dkim=pass (2048-bit key) header.d=vates.tech header.i=teddy.astie@vates.tech header.b="mOc/ycEf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1767739639; x=1768009639; bh=uG9dkpcyxG9XGIOrcqOgWZEBQUboGOvOW5SQQsgO9JQ=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=qj2CnuGhCvdJTuWSPzYhsMhFHXQ5vNNoChOj13qnC/NAyZNUB5XPW1DEIl9DGWxAC lU64WvIuvGPPOqhXzjYcGWPiYsO+5xuYXvL8RMnuv+pCtwT8gtDptE5QlA8mPrbTgJ IaC4gHJzq83XSC6cCZDCktr9snV/zR5FG01sceZKUuanfvnpAo0TcNhp223FEJxtBp CVkTGTSKV46jO43YuBOLpwh7SF3mJcFK0aG/m+oj4DcT4+UoxptByCcNIOZQiQ5bvf WQS0hHaiH7/HaMZNXogCY5xVUde4LhZHuiVRlHkj6UqMaXoVUSqS0K6amhZEikt5KB K232E2I9UIDaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1767739639; x=1768000139; i=teddy.astie@vates.tech; bh=uG9dkpcyxG9XGIOrcqOgWZEBQUboGOvOW5SQQsgO9JQ=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=mOc/ycEfT5b+z8VTCrfLwa7Y8j8QzDaXJkYEcfQ0LD0EiFIhBEUeUVW8GIbK1Hwgd NQNnys97SGZOCBkvPB0dfcxzIbb8C1moJgruWpMVQ/k8zW+/11e6uhVy0r6y4fe+7B bQJHiY+TOjjHI2blGv6BXILWiheMNAf7yfKShE9pRYqO6gZTe7i5PTC8A8+0Nz+NcB kMCwLYbW4RumBASByHDyyOEcDR8mDf6VzyFPaGm3PsEGdh+7CiBx39S7vigz6Xz0zC k+uRG38cKD+TpPkHCYzWbbxoRpNyG7Zzinc5bD8Jawg0Cc2qTRIM6S1dc3mK2NJizl 548dpUfaKa4zQ== Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-4.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4dm5s32wP0zlfgFg for ; Tue, 6 Jan 2026 22:47:19 +0000 (GMT) From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH]=20xen/virtio:=20Don't=20use=20grant-dma-ops=20when=20running=20as=20Dom0?= Received: from [37.26.189.201] by mandrillapp.com id 2d4781cd48254398bb0c388542d338fa; Tue, 06 Jan 2026 22:47:19 +0000 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1767739637478 Message-Id: <0b168d85-443c-4f38-92f8-8c008b2f8b82@vates.tech> To: "=?utf-8?Q?J=C3=BCrgen=20Gro=C3=9F?=" , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: "Stefano Stabellini" , "Oleksandr Tyshchenko" , "Boris Ostrovsky" References: <6698564dd2270a9f7377b78ebfb20cb425cabbe8.1767720955.git.teddy.astie@vates.tech> <995f7ac8-0a8b-43d9-9cc7-63622ec52ca1@suse.com> In-Reply-To: <995f7ac8-0a8b-43d9-9cc7-63622ec52ca1@suse.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.2d4781cd48254398bb0c388542d338fa?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260106:md Date: Tue, 06 Jan 2026 22:47:19 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 06/01/2026 =C3=A0 20:06, J=C3=BCrgen Gro=C3=9F a =C3=A9crit=C2=A0: > On 06.01.26 18:36, Teddy Astie wrote: >> Dom0 inherit devices from the machine and is usually in PV mode. >> If we are running in a virtual that has virtio devices, these devices >> would be considered as using grants with Dom0 as backend, while being >> the said Dom0 itself, while we want to use these devices like regular >> PCI devices. >> >> Fix this by preventing grant-dma-ops from being used when running as Dom= 0 >> (initial domain). We still keep the device-tree logic as-is. >> >> Signed-off-by: Teddy Astie >> Fixes: 61367688f1fb0 ("xen/virtio: enable grant based virtio on x86") >> --- >> CC: Juergen Gross >> CC: Stefano Stabellini >> CC: Oleksandr Tyshchenko >> CC: Boris Ostrovsky >> >> =C2=A0 drivers/xen/grant-dma-ops.c | 3 ++- >> =C2=A0 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c >> index 14077d23f2a1..c2603e700178 100644 >> --- a/drivers/xen/grant-dma-ops.c >> +++ b/drivers/xen/grant-dma-ops.c >> @@ -366,7 +366,8 @@ static int xen_grant_init_backend_domid(struct >> device *dev, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (np) { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D xen_dt_gr= ant_init_backend_domid(dev, np, backend_domid); >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of_node_put(np); >> -=C2=A0=C2=A0=C2=A0 } else if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT)= || >> xen_pv_domain()) { >> +=C2=A0=C2=A0=C2=A0 } else if (!xen_initial_domain() && >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (IS_ENABLE= D(CONFIG_XEN_VIRTIO_FORCE_GRANT) || >> xen_pv_domain())) { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dev_info(dev, "Us= ing dom0 as backend\n"); >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *backend_domid = =3D 0; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ret =3D 0; > > Please make this controllable, e.g. via a boot parameter. > > It is completely valid to have a virtio device in dom0 with the backend i= n > a domU. You'll need grants in this case. > Due to > *backend_domid =3D 0 Dom0 would always be the backend, unless we introduce a new boot parameter to select which domain will be the backend. There is also another issue, as in the xen_initial_domain() case, all PCI devices come from hardware. So no virtio-pci device can't come from another domain as Linux would pick up pcifront devices only if we are not a Dom0 (!xen_initial_domain()). > > Juergen Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech