From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
xen-devel <xen-devel@lists.xen.org>, HW42 <hw42@ipsumj.de>
Subject: Re: PCI passthrough with stubdomain
Date: Fri, 23 Sep 2016 20:56:43 +0200 [thread overview]
Message-ID: <20160923185643.GD31510@mail-itl> (raw)
In-Reply-To: <20160923145133.GM4441@var.bordeaux.inria.fr>
[-- Attachment #1.1: Type: text/plain, Size: 1719 bytes --]
On Fri, Sep 23, 2016 at 04:51:33PM +0200, Samuel Thibault wrote:
> Marek Marczykowski-Górecki, on Fri 23 Sep 2016 16:25:41 +0200, wrote:
> > Toolstack during (stub)domain startup setup two things, mostly
> > asynchronously:
> > 1. pciback/pcifront (through standard xenstore entries)
> > 2. instruct qemu to attach device (by writing "pci-ins" to
> > device-model/xxx/command)
>
> Ah, since pcifront_watches runs in a separate thread, it may not have
> called init_pcifront before qemu calls libpci, i.e. pcifront_scan.
Yes, exactly.
> I'd say that's where the fix should be: make pcifront_scan wait for
> init_pcifront to be done. It's however not so simple: we want to make
> pcifront_scan do nothing if no pciback is to be launched. My memory is
> rusty: is there something we are sure will show up in the xenstore when
> a pciback is to be launched? If so, pcifront_scan could do this: wait
> for pcifront_watches to have checked for the potential presence of
> pciback. If pciback is not to be started, just do nothing; if pciback is
> to be started, wait for init_pcifront to have been called by
> pcifront_watches. Then it will find the devices.
Ok. So, two questions:
1. How to do this? ;) I.e. what synchronization primitives are available
in mini-os? Just pthread_mutex_lock/unlock?
2. Wouldn't the same problem be with other stubdomain implementations?
Like Linux + qemu-xen or rumprun + qemu-xen? At least in Linux case
pcifront driver will also needs some time for initialization...
--
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?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-09-23 18:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-23 8:48 PCI passthrough with stubdomain Marek Marczykowski-Górecki
2016-09-23 9:22 ` Jan Beulich
2016-09-23 13:27 ` Samuel Thibault
2016-09-23 14:25 ` Marek Marczykowski-Górecki
2016-09-23 14:51 ` Samuel Thibault
2016-09-23 18:56 ` Marek Marczykowski-Górecki [this message]
2016-09-23 21:00 ` Samuel Thibault
2016-09-23 21:04 ` Marek Marczykowski-Górecki
2016-09-23 15:35 ` Konrad Rzeszutek Wilk
2016-09-23 18:47 ` Marek Marczykowski-Górecki
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=20160923185643.GD31510@mail-itl \
--to=marmarek@invisiblethingslab.com \
--cc=hw42@ipsumj.de \
--cc=samuel.thibault@ens-lyon.org \
--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).