Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-07-08 Thread Roger Pau Monné
On Fri, Jul 07, 2017 at 02:50:01PM -0700, Stefano Stabellini wrote: > On Fri, 7 Jul 2017, Roger Pau Monné wrote: > > On Thu, Jul 06, 2017 at 03:55:28PM -0500, Vikram Sethi wrote: > > > > > > AER: Will PCIe non-fatal and fatal errors (secondary bus reset for > > > > > > fatal) > > > > > > be > >

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-07-07 Thread Vikram Sethi
kram Sethi' <vikr...@qti.qualcomm.com>; > punit.agra...@arm.com; 'Sameer Goel' <sg...@qti.qualcomm.com>; 'xen- > devel' <xen-de...@lists.xenproject.org>; 'Sinan Kaya' > <ok...@qti.qualcomm.com>; 'Dave P Martin' <dave.mar...@arm.com>; > 'Vijaya Kumar K' <vi

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-07-07 Thread Stefano Stabellini
On Fri, 7 Jul 2017, Roger Pau Monné wrote: > On Thu, Jul 06, 2017 at 03:55:28PM -0500, Vikram Sethi wrote: > > > > > AER: Will PCIe non-fatal and fatal errors (secondary bus reset for > > > > > fatal) > > > > > be > > > recoverable in Xen? > > > > > Will drivers in doms be notified about fatal

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-07-07 Thread Roger Pau Monné
On Thu, Jul 06, 2017 at 03:55:28PM -0500, Vikram Sethi wrote: > > > > AER: Will PCIe non-fatal and fatal errors (secondary bus reset for > > > > fatal) > > > > be > > recoverable in Xen? > > > > Will drivers in doms be notified about fatal errors so they can be > > > > quiesced > > before doing

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-07-06 Thread Vikram Sethi
vikr...@qti.qualcomm.com>; Sinan > Kaya <ok...@qti.qualcomm.com>; Sameer Goel <sg...@qti.qualcomm.com>; > xen-devel <xen-de...@lists.xenproject.org>; Dave P Martin > <dave.mar...@arm.com>; Vijaya Kumar K > <vijaya.ku...@caviumnetworks.com> > Subject: Re:

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-07-04 Thread roger....@citrix.com
Hello, My 2cents on what are the plans on PVH/x86. On Wed, Jun 28, 2017 at 04:22:48PM +0100, Julien Grall wrote: > > > On 20/06/17 01:19, Vikram Sethi wrote: > > Hi Julien, > > Hi Vikram, > > Thank you for your feedbacks. > > > Thanks for posting this. I think some additional topics need to

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-07-03 Thread Julien Grall
On 29/06/17 16:17, Vikram Sethi wrote: Hi Julien, Hi Vikram, My thoughts are that while it is not essential to recover from AER and DPC initially, it is critical to at least take the slot offline and notify drivers so they quiesce. Without this basic handling, it is possible to create

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-06-29 Thread Vikram Sethi
Hi Julien, My thoughts are that while it is not essential to recover from AER and DPC initially, it is critical to at least take the slot offline and notify drivers so they quiesce. Without this basic handling, it is possible to create backups in some hardware that result in CPU hangs for

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-06-28 Thread Julien Grall
On 20/06/17 01:19, Vikram Sethi wrote: Hi Julien, Hi Vikram, Thank you for your feedbacks. Thanks for posting this. I think some additional topics need to be covered in the design document, under 3 main topics: I wanted to limit the scope of the PCI passthrough work to the strict

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-06-20 Thread Vikram Sethi
Hi Julien, Thanks for posting this. I think some additional topics need to be covered in the design document, under 3 main topics: Hotplug: how will Xen support hotplug? Many rootports may require firmware hooks such as ACPI ASL to take care of platform specific MMIO initialization on

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-06-15 Thread Stefano Stabellini
On Tue, 30 May 2017, Julien Grall wrote: > > > In this design document, we are considering that the host bridge driver > > > can > > > be ported in Xen. In the case it is not possible, a interface to forward > > > configuration space access would need to be defined. The interface details > > > is

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-06-15 Thread Stefano Stabellini
On Fri, 26 May 2017, Julien Grall wrote: > Hi all, > > The document below is an RFC version of a design proposal for PCI > Passthrough in Xen on ARM. It aims to describe from an high level perspective > the interaction with the different subsystems and how guest will be able > to discover and

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-30 Thread Julien Grall
Hi Roger, On 30/05/17 08:40, Roger Pau Monné wrote: On Fri, May 26, 2017 at 06:14:09PM +0100, Julien Grall wrote: [...] ## Who is in charge of the host bridge? There are numerous implementation of host bridges which exist on ARM. A part of them requires a specific driver as they cannot be

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-30 Thread Julien Grall
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

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-30 Thread Julien Grall
On 30/05/17 06:53, Manish Jaggi wrote: Hi Julien, On 5/29/2017 11:44 PM, Julien Grall wrote: On 05/29/2017 03:30 AM, Manish Jaggi wrote: Hi Julien, Hello Manish, On 5/26/2017 10:44 PM, Julien Grall wrote: PCI pass-through allows the guest to receive full control of physical PCI

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-30 Thread Roger Pau Monné
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 > > >

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-30 Thread Roger Pau Monné
On Fri, May 26, 2017 at 06:14:09PM +0100, Julien Grall wrote: [...] > ## Who is in charge of the host bridge? > > There are numerous implementation of host bridges which exist on ARM. A part > of > them requires a specific driver as they cannot be driven by a generic host > bridge > driver.

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-29 Thread Manish Jaggi
Hi Julien, On 5/29/2017 11:44 PM, Julien Grall wrote: On 05/29/2017 03:30 AM, Manish Jaggi wrote: Hi Julien, Hello Manish, On 5/26/2017 10:44 PM, Julien Grall wrote: PCI pass-through allows the guest to receive full control of physical PCI devices. This means the guest will have full

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-29 Thread Julien Grall
On 05/29/2017 03:30 AM, Manish Jaggi wrote: Hi Julien, Hello Manish, On 5/26/2017 10:44 PM, Julien Grall wrote: PCI pass-through allows the guest to receive full control of physical PCI devices. This means the guest will have full and direct access to the PCI device. ARM is supporting a

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-28 Thread Manish Jaggi
Hi Julien, On 5/26/2017 10:44 PM, Julien Grall wrote: Hi all, The document below is an RFC version of a design proposal for PCI Passthrough in Xen on ARM. It aims to describe from an high level perspective the interaction with the different subsystems and how guest will be able to discover and

[Xen-devel] [RFC] ARM PCI Passthrough design document

2017-05-26 Thread Julien Grall
Hi all, The document below is an RFC version of a design proposal for PCI Passthrough in Xen on ARM. It aims to describe from an high level perspective the interaction with the different subsystems and how guest will be able to discover and access PCI. Currently on ARM, Xen does not have any