Re: [Xen-devel] [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 30 Apr 2015, Vijay Kilari wrote:
> On Thu, Apr 30, 2015 at 3:45 PM, Stefano Stabellini
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> > On Thu, 30 Apr 2015, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 30/04/2015 11:02, Stefano Stabellini wrote:
> >> > 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.kilari@xxxxxxxxx>
> >> > > > wrote:
> >> > > > > On Wed, Apr 29, 2015 at 7:05 PM, Julien Grall
> >> > > > > <julien.grall@xxxxxxxxxx> 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.
> >>
> >> As said earlier, the number of DevBits implemented by the ITS can be 
> >> limited
> >> (see GITS_TYPER.Devbits).
> 
> ITS specs does not define how may of these bits corresponds to segment number.
> This is platform specific.
> 
> >>
> >> If the devid is not within this range, the ITS won't recognize the value 
> >> and
> >> won't be able to send the interrupt.
> >>
> >> So this is clearly not the right value.
> >
> > Sure, in that case the maximum value allowed by GITS_TYPER.Devbits.
> > Vijay, what is the value of GITS_TYPER.Devbits on your platform?
> 
> It is 21 bits

I would imagine that 21 bits would be plenty to find an unused devid.
Alternatively we could use an inexistent function of a real device, such
as 00:00.1 (function 1 of the host bridge).

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