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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.