From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
xen-devel@lists.xen.org, Wei Liu <wei.liu2@citrix.com>,
Samuel Thibault <samuel.thibault@ens-lyon.org>
Subject: Re: [PATCH 1/3] libxl: attach xen-pciback only to PV domains
Date: Tue, 25 Oct 2016 09:10:02 -0400 [thread overview]
Message-ID: <20161025131002.GA13171@char.us.oracle.com> (raw)
In-Reply-To: <20161019224233.GN15776@mail-itl>
On Thu, Oct 20, 2016 at 12:42:33AM +0200, Marek Marczykowski-Górecki 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órecki wrote:
> > > > HVM domains use IOMMU and device model assistance for communicating with
> > > > PCI devices, xen-pcifront/pciback is used only in PV domains.
> > >
> > > This bit of description is in line with my understanding of how PCI
> > > passthrough works.
> >
> > 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:
> >
> > echo <Bdf> > bind
>
> This part is still done.
>
> > And .. this is the important part - when device changes ownership.
> > That is when you disconnect it from one guest and assign to another.
> > You need to reset the device in between. The code that calls
> > the pci_reset_function is called by:
> >
> > }
> >
> > /*
> > * Called when:
> > * - XenBus state has been reconfigure (pci unplug). See xen_pcibk_remove_device
> > * - XenBus state has been disconnected (guest shutdown). See xen_pcibk_xenbus_remove
>
> But this, in case of HVM without stubdomain, is not.
>
> > * - 'echo BDF > unbind' on pciback module with no guest attached. See pcistub_remove
> > * - 'echo BDF > unbind' with a guest still using it. See pcistub_remove
> > *
> > * As such we have to be careful.
> > *
> > * To make this easier, the caller has to hold the device lock.
> > */
> > void pcistub_put_pci_dev(struct pci_dev *dev)
> >
> > The first two are done when XenStore 'pci' entries are active - which
> > this patch will remove and introduce a potential security problem.
> >
> > Unless libxl does an 'unbind' followed by an 'bind'?
>
> 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?
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.
I need to look in the Linux code to confirm what the tricky part was.
>
>
> >
> > >
> > > > When HVM domain has device model in stubdomain, attaching xen-pciback to
> > > > the target domain itself is not only useless, but also may prevent
> > > > attaching xen-pciback to the stubdomain, effectively breaking PCI
> > > > passthrough.
> > > >
> > > > Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> > > > ---
> > > > tools/libxl/libxl_pci.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> > > > index 6f8f49c..2ae1bc4 100644
> > > > --- a/tools/libxl/libxl_pci.c
> > > > +++ b/tools/libxl/libxl_pci.c
> > > > @@ -1111,7 +1111,7 @@ out:
> > > > }
> > > > }
> > > >
> > > > - if (!starting)
> > > > + if (!starting && !hvm)
> > > > rc = libxl__device_pci_add_xenstore(gc, domid, pcidev, starting);
> > > > else
> > > > rc = 0;
> > > > @@ -1306,7 +1306,8 @@ static void libxl__add_pcidevs(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
> > > > }
> > > > }
> > > >
> > > > - if (d_config->num_pcidevs > 0) {
> > > > + if (d_config->num_pcidevs > 0
> > > > + && d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV) {
> > >
> > > Please move the indentation forward.
> > >
> > > > rc = libxl__create_pci_backend(gc, domid, d_config->pcidevs,
> > > > d_config->num_pcidevs);
> > > > if (rc < 0) {
> > > > --
> > > > 2.5.5
> > > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > https://lists.xen.org/xen-devel
>
> --
> Best Regards,
> Marek Marczykowski-Górecki
> 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?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-10-25 13:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 1:53 [PATCH 0/3] Fix PCI passthrough for HVM with stubdomain Marek Marczykowski-Górecki
2016-10-18 1:53 ` [PATCH 1/3] libxl: attach xen-pciback only to PV domains Marek Marczykowski-Górecki
2016-10-18 20:52 ` Konrad Rzeszutek Wilk
2016-10-18 21:03 ` Marek Marczykowski-Górecki
2016-10-19 9:37 ` Wei Liu
2016-10-19 20:46 ` Konrad Rzeszutek Wilk
2016-10-19 22:42 ` Marek Marczykowski-Górecki
2016-10-25 13:10 ` Konrad Rzeszutek Wilk [this message]
2016-10-25 19:22 ` Marek Marczykowski-Górecki
2016-10-25 19:42 ` Andrew Cooper
2016-10-18 1:53 ` [PATCH 2/3] libxl: attach PCI device to qemu only after setting pciback/pcifront Marek Marczykowski-Górecki
2016-10-19 9:37 ` Wei Liu
2016-10-18 1:53 ` [PATCH 3/3] libxl: don't try to manipulate json config for stubdomain Marek Marczykowski-Górecki
2016-10-19 9:38 ` Wei Liu
2016-10-19 10:32 ` Marek Marczykowski-Górecki
2016-10-18 18:44 ` [PATCH 0/3] Fix PCI passthrough for HVM with stubdomain Samuel Thibault
-- strict thread matches above, loose matches on Subject: below --
2016-10-18 23:07 [PATCH 1/3] libxl: attach xen-pciback only to PV domains Juergen Schinker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161025131002.GA13171@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=ian.jackson@eu.citrix.com \
--cc=marmarek@invisiblethingslab.com \
--cc=samuel.thibault@ens-lyon.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).