On Wed, 29 Apr 2015, Julien Grall wrote: > On 29/04/15 17:30, Vijay Kilari wrote: > > On Wed, Apr 29, 2015 at 9:56 PM, Vijay Kilari <vijay.kil...@gmail.com> > > wrote: > >> On Wed, Apr 29, 2015 at 7:05 PM, Julien Grall <julien.gr...@citrix.com> > >> wrote: > >>> On 29/04/15 12:56, Julien Grall wrote: > >>>> As the 2 suggested approach don't seem to fit our usage, we need to find > >>>> another approach. > >>> > >>> I think I have another approach which doesn't require interrupt neither > >>> polling in EL2. > >> > >> I could resolve all the issues around approach 1 > >> only concern is generating dummy/fake device id. > > This is a big concern. We can't hardcode the devID because a real device > could use it later. Having an ID generating at the boot time wouldn't be > better because it could be broken with device hotplug. > > It's very unfortunate that the ITS doesn't have a reserved interrupt.
Indeed, but it is an issue that can be overcome. We should just use an out-of-range devid. One that cannot be hot-plugged later. The one proposed by Vijay is actually not a bad idea (segment number 0xff). Segment numbers correspond to MCFG config spaces. There is usually one per root complex, but theoretically I think one root complex could have more. I don't think is possible to hot-plug a root complex, so if one is spare at boot time, we should be safe. Even if it was possible, we could still return error from PHYSDEVOP_pci_host_bridge_add if the segment number overlaps (see http://marc.info/?l=xen-devel&m=142495489932714). So I think we should just go ahead and use PLAT_DUMMY_SEG 0xff. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
