All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: edgar.iglesias@xilinx.com,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Chen <Wei.Chen@arm.com>, Steve Capper <Steve.Capper@arm.com>,
	Manish Jaggi <mjaggi@caviumnetworks.com>,
	manish.jaggi@caviumnetworks.com, punit.agrawal@arm.com,
	vikrams@qti.qualcomm.com, okaya@qti.qualcomm.com, "Goel,
	Sameer" <sgoel@qti.qualcomm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Dave P Martin <Dave.Martin@arm.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
Subject: Re: [RFC] ARM PCI Passthrough design document
Date: Tue, 30 May 2017 10:42:22 +0100	[thread overview]
Message-ID: <10421036-9821-f40b-4312-480bc7879f02@linaro.org> (raw)
In-Reply-To: <20170530075339.3e4njiuaduxujp43@dhcp-3-128.uk.xensource.com>

Hi Roger,

On 30/05/17 08:53, Roger Pau Monné wrote:
> On Mon, May 29, 2017 at 07:14:55PM +0100, Julien Grall wrote:
>> On 05/29/2017 03:30 AM, Manish Jaggi wrote:
>>> On 5/26/2017 10:44 PM, Julien Grall wrote:
> [...]
>>>> ## Discovering and registering PCI devices
>>>>
>>>> The hardware domain will scan the host bridge to find the list of PCI
>>>> devices
>>>> available and then report it to Xen using the existing hypercall
>>>> PHYSDEV_pci_device_add:
>>>>
>>>> #define XEN_PCI_DEV_EXTFN   0x1
>>>> #define XEN_PCI_DEV_VIRTFN  0x2
>>>> #define XEN_PCI_DEV_PXM     0x3
>>>>
>>>> struct physdev_pci_device_add {
>>>>      /* IN */
>>>>      uint16_t    seg;
>>>>      uint8_t     bus;
>>>>      uint8_t     devfn;
>>>>      uint32_t    flags;
>>>>      struct {
>>>>          uint8_t bus;
>>>>          uint8_t devfn;
>>>>      } physfn;
>>>>      /*
>>>>       * Optional parameters array.
>>>>       * First element ([0]) is PXM domain associated with the device (if
>>>>       * XEN_PCI_DEV_PXM is set)
>>>>       */
>>>>      uint32_t optarr[0];
>>>> }
>>> For mapping the MMIO space of the device in Stage2, we need to add
>>> support in Xen / via a map hypercall in linux/drivers/xen/pci.c
>>
>> Mapping MMIO space in stage-2 is not PCI specific and already addressed in
>> Xen 4.9 (see commit 80f9c31 "xen/arm: acpi: Map MMIO on fault in stage-2
>> page table for the hardware domain"). So I don't understand why we should
>> care about that here...
>
> I'm not sure what Manish means, but you should map the BARs of the
> device when adding it to a domain.

This could be done when configuring the BARs. Today for DOM0, we rely 
either on trapping or XENMEM_add_to_add_physmap.

But I still don't understand why it matters so much in the design 
document. This is really an implementation details.

> Doing mapping on faults will work
> with CPU accesses, but it's not going to work with SMMU faults, those are
> asynchronous, and I don't think you can guarantee that the CPU is
> always going to access the BARs before doing any DMA transactions to
> them.

Why would you do DMA using BARs? I thought DMA was only to/from memory?

>
> Note that Xen can also scan the bridge by itself and add the devices,
> I'm not sure you need the PHYSDEV_pci_device_add hypercall.

This should work today without any knowledge of PCIs in Xen. I am not 
aware of any failures with the current approach implemented. If you 
think it does not work, then please give a concrete example.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-05-30  9:42 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 17:14 [RFC] ARM PCI Passthrough design document Julien Grall
2017-05-29  2:30 ` Manish Jaggi
2017-05-29 18:14   ` Julien Grall
2017-05-30  5:53     ` Manish Jaggi
2017-05-30  9:33       ` Julien Grall
2017-05-30  7:53     ` Roger Pau Monné
2017-05-30  9:42       ` Julien Grall [this message]
2017-05-30  7:40 ` Roger Pau Monné
2017-05-30  9:54   ` Julien Grall
2017-06-16  0:31     ` Stefano Stabellini
2017-06-16  0:23 ` Stefano Stabellini
2017-06-20  0:19 ` Vikram Sethi
2017-06-28 15:22   ` Julien Grall
2017-06-29 15:17     ` Vikram Sethi
2017-07-03 14:35       ` Julien Grall
2017-07-04  8:30     ` roger.pau
2017-07-06 20:55       ` Vikram Sethi
2017-07-07  8:49         ` Roger Pau Monné
2017-07-07 21:50           ` Stefano Stabellini
2017-07-07 23:40             ` Vikram Sethi
2017-07-08  7:34             ` Roger Pau Monné
2018-01-19 10:34               ` Manish Jaggi
2017-07-19 14:41 ` Notes from PCI Passthrough design discussion at Xen Summit Punit Agrawal
2017-07-20  3:54   ` Manish Jaggi
2017-07-20  8:24     ` Roger Pau Monné
2017-07-20  9:32       ` Manish Jaggi
2017-07-20 10:29         ` Roger Pau Monné
2017-07-20 10:47           ` Julien Grall
2017-07-20 11:06             ` Roger Pau Monné
2017-07-20 11:52               ` Julien Grall
2017-07-20 11:02           ` Manish Jaggi
2017-07-20 10:41         ` Julien Grall
2017-07-20 11:00           ` Manish Jaggi
2017-07-20 12:24             ` Julien Grall
2018-01-22 11:10 ` [RFC] ARM PCI Passthrough design document Manish Jaggi

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=10421036-9821-f40b-4312-480bc7879f02@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Dave.Martin@arm.com \
    --cc=Steve.Capper@arm.com \
    --cc=Vijaya.Kumar@caviumnetworks.com \
    --cc=Wei.Chen@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=edgar.iglesias@xilinx.com \
    --cc=manish.jaggi@caviumnetworks.com \
    --cc=mjaggi@caviumnetworks.com \
    --cc=okaya@qti.qualcomm.com \
    --cc=punit.agrawal@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sgoel@qti.qualcomm.com \
    --cc=sstabellini@kernel.org \
    --cc=vikrams@qti.qualcomm.com \
    --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.