From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH 1/3] libxl: attach xen-pciback only to PV domains Date: Tue, 25 Oct 2016 21:22:44 +0200 Message-ID: <20161025192244.GC1136@mail-itl> References: <1476755613-3921-1-git-send-email-marmarek@invisiblethingslab.com> <1476755613-3921-2-git-send-email-marmarek@invisiblethingslab.com> <20161019093752.GE2639@citrix.com> <20161019204626.GF17142@char.us.oracle.com> <20161019224233.GN15776@mail-itl> <20161025131002.GA13171@char.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3339521089696466065==" Return-path: In-Reply-To: <20161025131002.GA13171@char.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Konrad Rzeszutek Wilk Cc: Ian Jackson , xen-devel@lists.xen.org, Wei Liu , Samuel Thibault List-Id: xen-devel@lists.xenproject.org --===============3339521089696466065== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pMRnfHSWYEVtk438" Content-Disposition: inline --pMRnfHSWYEVtk438 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2016 at 09:10:02AM -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Oct 20, 2016 at 12:42:33AM +0200, Marek Marczykowski-G=C3=B3reck= i wrote: > > On Wed, Oct 19, 2016 at 04:46:26PM -0400, Konrad Rzeszutek Wilk wrote:= > > > On Wed, Oct 19, 2016 at 10:37:52AM +0100, Wei Liu wrote: > > > > On Tue, Oct 18, 2016 at 03:53:31AM +0200, Marek Marczykowski-G=C3=B3= recki wrote: > > > > > HVM domains use IOMMU and device model assistance for communicat= ing with > > > > > PCI devices, xen-pcifront/pciback is used only in PV domains. > > > >=20 > > > > This bit of description is in line with my understanding of how PC= I > > > > passthrough works. > > >=20 > > > Kind of. Pciback is also used to "own" the PCI devices. And in fact > > > they do an important job of resetting the PCI device when the > > > device is "bind" to pciback: > > >=20 > > > echo > bind > >=20 > > This part is still done. > >=20 > > > And .. this is the important part - when device changes ownership. > > > That is when you disconnect it from one guest and=20assign to anothe= r. > > > You need to reset the device in between. The code that calls > > > the pci_reset_function is called by: > > >=20 > > > } = =20 > > > = =20 > > > /* = =20 > > > * Called when: = =20 > > > * - XenBus state has been reconfigure (pci unplug). See xen_pcibk_= remove_device > > > * - XenBus state has been disconnected (guest shutdown). See xen_p= cibk_xenbus_remove > >=20 > > But this, in case of HVM without stubdomain, is not. > >=20 > > > * - 'echo BDF > unbind' on pciback module with no guest attached. = See pcistub_remove > > > * - 'echo BDF > unbind' with a guest still using it. See pcistub_r= emove =20 > > > * = =20 > > > * As such we have to be careful. = =20 > > > * = =20 > > > * To make this easier, the caller has to hold the device lock. = =20 > > > */ = =20 > > > void pcistub_put_pci_dev(struct pci_dev *dev) > > >=20 > > > The first two are done when XenStore 'pci' entries are active - whic= h > > > this patch will remove and introduce a potential security problem. > > >=20 > > > Unless libxl does an 'unbind' followed by an 'bind'? > >=20 > > What about libxl__device_pci_reset, which is called (at least) before > > attaching device to some domain, even after my patch and even if the > > device is already bound to pciback. It tries to reset the device using= > > 'reset' entry in sysfs. I see this isn't available for some devices - > > can pci_reset_function do any better? >=20 > My vague recollection was that it tried to do it but it aborted > earlier due to holding locks (dev_lock is held when you do any > operation on the SysFS). But I may be forgetting the details. >=20 > I need to look in the Linux code to confirm what the tricky part was. Thanks. This is the last thing holding me from sending v2. Anyway, if attaching xen-pciback to /something/ is needed, how should it look? We have 3 cases: 1. PV - without qemu 2. HVM - with qemu in dom0 3. HVM - with qemu in stubdomain And soon there will be 4th: PVH - without qemu For 1 and 4 the device should be attached (in terms of xenstore) to the target domain, as xen-pcifront (or equivalent) running there will be used. BTW is that true for PVHv2? For 3 - it should be attached to stubdomain (which is the case). The question is what about 2 - should it be attached to the target domain,= even though it will not be used? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --pMRnfHSWYEVtk438 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYD7EFAAoJENuP0xzK19cs8IAH/A2sNvaZiD8JAwgjEUqbphqX JfwNTSmQnkz3DlosGH0brP4S3ZNR0upZQq/1/t9t4lpjSL81coXrfTDOBDugPpDG 35nEyq0k0IAVdZjb4drZm1m0RjtDuhsPqmvSquMXLDvY9nj+1OJjH9flb2b8flax zdO6LtPI1BzYe0h5BxvC/l/GPf0btc4Nd8uOKNLaYuhK04eYji1J4bJm/D4zhP7u SeWlo3f/ARvQbN08ejthzUudI2NJy3e4M2ENB0Qf9HCl2sFj5tyuyoxbRPEmLUK4 43tb3rJhO3b692oIjspyJpxfW1cmkNJB5SAHoYAkYAshch1kgZ3erSHXxb2e+j4= =6FAu -----END PGP SIGNATURE----- --pMRnfHSWYEVtk438-- --===============3339521089696466065== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3339521089696466065==--