All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
Cc: "Rahul Singh" <Rahul.Singh@arm.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	nd <nd@arm.com>, "Julien Grall" <julien.grall.oss@gmail.com>
Subject: Re: RFC: PCI devices passthrough on Arm design proposal
Date: Fri, 17 Jul 2020 14:49:09 +0100	[thread overview]
Message-ID: <239b5114-9e23-ab55-41b9-c02a2018e4ab@xen.org> (raw)
In-Reply-To: <F91FCC13-D591-4A57-9840-220614174F02@arm.com>



On 17/07/2020 14:44, Bertrand Marquis wrote:
> 
> 
>> On 17 Jul 2020, at 15:29, Julien Grall <julien@xen.org> wrote:
>>
>>
>>
>> On 17/07/2020 14:22, Bertrand Marquis 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.
>>>>>
>>>>> A new area has been reserved in the arm guest physical map at which
>>>>> the VPCI bus is declared in the device tree (reg and ranges
>>>>> parameters of the node). A trap handler for the PCI ECAM access from
>>>>> guest has been registered at the defined address and redirects
>>>>> requests to the VPCI driver in Xen.
>>>>
>>>> Can't you deduce the requirement of such DT node based on the presence
>>>> of a 'pci=' option in the same config file?
>>>>
>>>> Also I wouldn't discard that in the future you might want to use
>>>> different emulators for different devices, so it might be helpful to
>>>> introduce something like:
>>>>
>>>> pci = [ '08:00.0,backend=vpci', '09:00.0,backend=xenpt', '0a:00.0,backend=qemu', ... ]
>>
>> I like this idea :).
>>
>>>>
>>>> For the time being Arm will require backend=vpci for all the passed
>>>> through devices, but I wouldn't rule out this changing in the future.
>>> We need it for the case where no device is declared in the config file and the user
>>> wants to add devices using xl later. In this case we must have the DT node for it
>>> to work.
>>
>> Are you suggesting that you plan to implement PCI hotplug?
> 
> No this is not in the current plan but we should not prevent this to be supported some day :-)

I agree that we don't want to prevent extension. But I fail to see why 
this would be an issue if we don't introduce the option "vcpi" today.

Cheers,

-- 
Julien Grall


  reply	other threads:[~2020-07-17 13:49 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
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 [this message]
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=239b5114-9e23-ab55-41b9-c02a2018e4ab@xen.org \
    --to=julien@xen.org \
    --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.