From: Jan Beulich <jbeulich@suse.com>
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
Cc: "Rahul Singh" <Rahul.Singh@arm.com>,
"Julien Grall" <julien.grall.oss@gmail.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
nd <nd@arm.com>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: RFC: PCI devices passthrough on Arm design proposal
Date: Fri, 17 Jul 2020 15:19:41 +0200 [thread overview]
Message-ID: <1dd5db2d-98c7-7738-c3d4-d3f098dfe674@suse.com> (raw)
In-Reply-To: <28899FEF-9DA7-4513-8283-1AC5EFFC6E92@arm.com>
On 17.07.2020 15:14, Bertrand Marquis wrote:
>> On 17 Jul 2020, at 10:10, Jan Beulich <jbeulich@suse.com> wrote:
>> On 16.07.2020 19:10, Rahul Singh wrote:
>>> # Emulated PCI device tree node in libxl:
>>>
>>> Libxl is creating a virtual PCI device tree node in the device tree to enable the guest OS to discover the virtual PCI during guest boot. We introduced the new config option [vpci="pci_ecam"] for guests. When this config option is enabled in a guest configuration, a PCI device tree node will be created in the guest device tree.
>>
>> I support Stefano's suggestion for this to be an optional thing, i.e.
>> there to be no need for it when there are PCI devices assigned to the
>> guest anyway. I also wonder about the pci_ prefix here - isn't
>> vpci="ecam" as unambiguous?
>
> This could be a problem as we need to know that this is required for a guest upfront so that PCI devices can be assigned after using xl.
I'm afraid I don't understand: When there are no PCI device that get
handed to a guest when it gets created, but it is supposed to be able
to have some assigned while already running, then we agree the option
is needed (afaict). When PCI devices get handed to the guest while it
gets constructed, where's the problem to infer this option from the
presence of PCI devices in the guest configuration?
Jan
next prev parent reply other threads:[~2020-07-17 13:19 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3F6E40FB-79C5-4AE8-81CA-E16CA37BB298@arm.com>
[not found] ` <BD475825-10F6-4538-8294-931E370A602C@arm.com>
2020-07-16 17:10 ` RFC: PCI devices passthrough on Arm design proposal Rahul Singh
2020-07-16 20:51 ` Stefano Stabellini
2020-07-17 6:53 ` Bertrand Marquis
2020-07-17 7:41 ` Oleksandr Andrushchenko
2020-07-17 11:26 ` Julien Grall
2020-07-17 11:41 ` Oleksandr Andrushchenko
2020-07-17 13:21 ` Bertrand Marquis
2020-07-17 12:46 ` Rahul Singh
2020-07-17 12:55 ` Jan Beulich
2020-07-17 13:12 ` Bertrand Marquis
2020-07-17 8:10 ` Jan Beulich
2020-07-17 8:47 ` Oleksandr Andrushchenko
2020-07-17 13:28 ` Rahul Singh
2020-07-17 13:14 ` Bertrand Marquis
2020-07-17 13:19 ` Jan Beulich [this message]
2020-07-17 13:59 ` Bertrand Marquis
2020-07-17 14:06 ` Jan Beulich
2020-07-17 14:34 ` Bertrand Marquis
2020-07-17 14:41 ` Roger Pau Monné
2020-07-17 14:49 ` Bertrand Marquis
2020-07-17 15:05 ` Roger Pau Monné
2020-07-17 15:23 ` Bertrand Marquis
2020-07-17 15:30 ` Roger Pau Monné
2020-07-17 15:51 ` Bertrand Marquis
2020-07-17 16:08 ` Roger Pau Monné
2020-07-17 16:18 ` Julien Grall
2020-07-17 19:17 ` Oleksandr
2020-07-18 9:58 ` Bertrand Marquis
2020-07-18 11:24 ` Julien Grall
2020-07-20 11:27 ` Oleksandr
2020-07-20 8:47 ` Roger Pau Monné
2020-07-20 9:24 ` Julien Grall
2020-07-20 23:23 ` Stefano Stabellini
2020-07-21 9:54 ` Rahul Singh
2020-07-17 11:16 ` Roger Pau Monné
2020-07-17 13:22 ` Bertrand Marquis
2020-07-17 13:29 ` Julien Grall
2020-07-17 13:44 ` Bertrand Marquis
2020-07-17 13:49 ` Julien Grall
2020-07-17 14:01 ` Bertrand Marquis
2020-07-17 14:31 ` Roger Pau Monné
2020-07-17 15:21 ` Bertrand Marquis
2020-07-17 15:55 ` Roger Pau Monné
2020-07-18 9:49 ` Bertrand Marquis
2020-07-20 8:45 ` Roger Pau Monné
2020-07-20 23:24 ` Stefano Stabellini
2020-07-21 1:39 ` Rob Herring
2020-07-21 19:35 ` Stefano Stabellini
[not found] ` <8ac91a1b-e6b3-0f2b-0f23-d7aff100936d@xen.org>
2020-07-17 13:50 ` Julien Grall
2020-07-17 13:59 ` Jan Beulich
2020-07-17 14:12 ` Julien Grall
2020-07-17 14:23 ` Jan Beulich
2020-07-17 14:47 ` Bertrand Marquis
2020-07-17 15:26 ` Julien Grall
2020-07-17 15:47 ` Bertrand Marquis
2020-07-17 16:05 ` Roger Pau Monné
2020-07-18 9:55 ` Bertrand Marquis
2020-07-18 11:14 ` Julien Grall
2020-07-20 11:32 ` Rahul Singh
2020-07-18 11:32 ` Julien Grall
2020-07-18 11:08 ` Julien Grall
2020-07-20 11:26 ` Rahul Singh
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=1dd5db2d-98c7-7738-c3d4-d3f098dfe674@suse.com \
--to=jbeulich@suse.com \
--cc=Bertrand.Marquis@arm.com \
--cc=Rahul.Singh@arm.com \
--cc=julien.grall.oss@gmail.com \
--cc=nd@arm.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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.