Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

Sure, I would be happy to, but unfortunately Jan won't be attending.

On Fri, 14 Aug 2015, Jaggi, Manish wrote:
> How about having  a short discussion on Monday during Xen Summit to discuss 
> on the points.
> We have a talk tuesday morning and I would update it based on the monday 
> discussion.
> 
> Regards,
> Manish Jaggi
> 
> ________________________________________
> From: xen-devel-bounces@xxxxxxxxxxxxx <xen-devel-bounces@xxxxxxxxxxxxx> on 
> behalf of Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> Sent: Friday, August 14, 2015 9:08 PM
> To: Jan Beulich
> Cc: Prasun.kapoor@xxxxxxxxxx; Ian Campbell; stefano.stabellini@xxxxxxxxxxxxx; 
> Jaggi, Manish; Kumar, Vijaya; Julien Grall; Xen Devel
> Subject: Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4
> 
> On Thu, 13 Aug 2015, Jan Beulich wrote:
> >                >>> On 13.08.15 at 11:42, <mjaggi@xxxxxxxxxxxxxxxxxx> wrote:
> > >   2.1    pci_hostbridge and pci_hostbridge_ops
> > >   
> > > -----------------------------------------------------------------------------
> > >   The init function in the PCI host driver calls to register hostbridge
> > >   callbacks:
> > >
> > >   int pci_hostbridge_register(pci_hostbridge_t *pcihb);
> > >
> > >   struct pci_hostbridge_ops {
> > >       u32 (*pci_conf_read)(struct pci_hostbridge*, u32 bus, u32 devfn,
> > >                                   u32 reg, u32 bytes);
> > >       void (*pci_conf_write)(struct pci_hostbridge*, u32 bus, u32 devfn,
> > >                                   u32 reg, u32 bytes, u32 val);
> > >   };
> > >
> > >   struct pci_hostbridge{
> > >       u32 segno;
> > >       paddr_t cfg_base;
> > >       paddr_t cfg_size;
> > >       struct dt_device_node *dt_node;
> > >       struct pci_hostbridge_ops ops;
> > >       struct list_head list;
> > >   };
> > >
> > >   A PCI conf_read function would internally be as follows:
> > >   u32 pcihb_conf_read(u32 seg, u32 bus, u32 devfn,u32 reg, u32 bytes)
> > >   {
> > >       pci_hostbridge_t *pcihb;
> > >       list_for_each_entry(pcihb, &pci_hostbridge_list, list)
> > >       {
> > >           if(pcihb-segno == seg)
> > >               return pcihb-ops.pci_conf_read(pcihb, bus, devfn, reg, 
> > > bytes);
> > >       }
> > >       return -1;
> > >   }
> >
> > Which implies 1 segment per host bridge, which doesn't seem too
> > nice to me: I can't see why a bridge might not cover more than one
> > segment, and I also can't see why you shouldn't be able to put
> > multiple bridges in the same segment when the number of busses
> > they have is small.
> 
> 1 segment per host bridge is an ARM IORT requirement
> (http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf).
> It is also pretty much in the spirit of the MCFG table, even though it
> is not spelled out so clearly there. I know that we are talking about
> device tree here, but I think it is safe to keep the same constraint.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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