From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail187-10.suw11.mandrillapp.com (mail187-10.suw11.mandrillapp.com [198.2.187.10]) (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 69B0E6EB7C for ; Fri, 21 Jun 2024 15:09:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.2.187.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718982551; cv=none; b=GVWYrnOlJYleXsyywJdxCm9JpQrZ0i6mDpbysOxhr9mdUjujcRuoBU+7fvayEKEiscDQp54ce6c5TDpKkYuH2Dt0OdkIeLeUQXn/deidc/B+esVTLrjjMzoJ7bE1K996Uw54CNevnQNgMeJQvzb97x+A0VGY3YrHycYfA7sNLjM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718982551; c=relaxed/simple; bh=ZyhlVR6pq1OHkcy+fRhQISyNOfVTZYNFalKZNst49eo=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Date: MIME-Version:Content-Type; b=HB+Im53m8dOv66RQp75BFWoC+olxX1eFPPV/Zzzgri4+rhlLXRXR90VWVFGSwpBfC09NdxD0LZqXxVng+3EF9rqaxmRPhRAQG4JJhHllZ49N/XM64w8xltpPK9uR6zBQ8NyGaw3DjEw4agZ62NsH3IvRPtdQEoJVD70YmqFt0Vc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine 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=gnYPzEPA; dkim=pass (2048-bit key) header.d=vates.tech header.i=teddy.astie@vates.tech header.b=GV1bbXFF; arc=none smtp.client-ip=198.2.187.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine 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="gnYPzEPA"; dkim=pass (2048-bit key) header.d=vates.tech header.i=teddy.astie@vates.tech header.b="GV1bbXFF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1718982548; x=1719243048; bh=lIV/U0ezGsXVmOjqbkafB5BjfIUquJ6q+7BRog7b6qo=; 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=gnYPzEPAuHv5IFdfKKkh/CwhCdlAdKKm0Wz8adR7g9EyQug2oplChvNVVVLyi/ZNR qpyCUa7W4lJlVzsfcKXxnCgwbt03J6ZbvFa3bLp7ZwQo7mMVmgC8BQfcbAvAPhUJap HkurX0avjtzxSL/iJ02Ed87OdDvZRerd4AGwNALFxoS5kDI7Zh9wMt85tvn3esiou9 L7n0oUUdZH3ahi8tU2dsL9RCqCdWDu4rajY5L2tFdWZ6C46I5kcAbnl2XWRI5K2QTc THT1AzBQ71mdeEvcaNlPBOFA8VH23K7JWDqBJD4kMgBeE+KHRYw3kxKsXav/7w7Bte YrvPkD1+9UdUw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1718982548; x=1719243048; i=teddy.astie@vates.tech; bh=lIV/U0ezGsXVmOjqbkafB5BjfIUquJ6q+7BRog7b6qo=; 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=GV1bbXFF1LgGXDJHgJlI0dsXBzt/XQ29AGxzHN17K2TafFRPAAJBhpiDOILQcgrUf HDhLw8cp6y1FlB/W523p8v6GxkVgVViFcm89+Do0MovrU0XixOXPX1i3vua/scx2k6 Yuz1k13lPAX95jlAEmNj9MiyTZ7gbXPSC0Uqgf16VqEwIiPTTMB0fIx2lDOXpdzstt +UFeqt40y0z6eqJ5q7grjOkeTKhA0qakRt2rWQlVDiy2UE2IAPOHsFyVTgjmQBsam/ SLyRBnkgzaRgv8dtVf+Qowotmgkx/QDJXUU/g4u98kfcd11h7p6WQortJNVYe6U32p XSogVqNrxSIPA== Received: from pmta09.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail187-10.suw11.mandrillapp.com (Mailchimp) with ESMTP id 4W5LNh2FLpz5QkLlV for ; Fri, 21 Jun 2024 15:09:08 +0000 (GMT) From: Teddy Astie Subject: =?utf-8?Q?Re:=20[RFC=20PATCH]=20iommu/xen:=20Add=20Xen=20PV-IOMMU=20driver?= Received: from [37.26.189.201] by mandrillapp.com id 019a5b03f90e4bd8b7a97a415c19f472; Fri, 21 Jun 2024 15:09:08 +0000 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1718982546557 Message-Id: <750967b7-252f-4523-872f-64b79358c97c@vates.tech> To: Jason Gunthorpe Cc: xen-devel@lists.xenproject.org, iommu@lists.linux.dev, Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Joerg Roedel , Will Deacon , Robin Murphy , =?utf-8?Q?Marek=20Marczykowski-G=C3=B3recki?= References: <20240619163000.GK791043@ziepe.ca> In-Reply-To: <20240619163000.GK791043@ziepe.ca> 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.019a5b03f90e4bd8b7a97a415c19f472?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240621:md Date: Fri, 21 Jun 2024 15:09:08 +0000 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Jason, Le 19/06/2024 =C3=A0 18:30, Jason Gunthorpe a =C3=A9crit=C2=A0: > On Thu, Jun 13, 2024 at 01:50:22PM +0000, Teddy Astie wrote: > >> +struct iommu_domain *xen_iommu_domain_alloc(unsigned type) >> +{ >> +=09struct xen_iommu_domain *domain; >> +=09u16 ctx_no; >> +=09int ret; >> + >> +=09if (type & IOMMU_DOMAIN_IDENTITY) { >> +=09=09/* use default domain */ >> +=09=09ctx_no =3D 0; > > Please use the new ops, domain_alloc_paging and the static identity domai= n. Yes, in the v2, I will use this newer interface. I have a question on this new interface : is it valid to not have a identity domain (and "default domain" being blocking); well in the current implementation it doesn't really matter, but at some point, we may want to allow not having it (thus making this driver mandatory). > >> +static struct iommu_group *xen_iommu_device_group(struct device *dev) >> +{ >> +=09if (!dev_is_pci(dev)) >> +=09=09return ERR_PTR(-ENODEV); >> + > > device_group is only called after probe_device, since you already > exclude !pci during probe there is no need for this wrapper, just set > the op directly to pci_device_group. > >> +=09if (!dev_is_pci(dev)) >> +=09=09return; > > No op is ever called on a non-probed device, remove all these checks. > > > A paging domain should be the only domain ops that have a populated > map so this should be made impossible by construction Makes sense, will remove these redundant checks in v2. > >> +static void xen_iommu_release_device(struct device *dev) >> +{ >> +=09int ret; >> +=09struct pci_dev *pdev; >> +=09struct pv_iommu_op op =3D { >> +=09=09.subop_id =3D IOMMUOP_reattach_device, >> +=09=09.flags =3D 0, >> +=09=09.ctx_no =3D 0 /* reattach device back to default context */ >> +=09}; > > Consider if you can use release_domain for this, I think this is > probably a BLOCKED domain behavior. The goal is to put back all devices where they were at the beginning (the default "context"), which is what release_domain looks like it is doing. Will use it for v2. > > Jason Teddy Teddy Astie | Vates XCP-ng Intern XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech