[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.