From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support Date: Thu, 30 Apr 2015 11:09:21 +0100 Message-ID: <5541FF51.6060907@citrix.com> References: <1426775889-29442-1-git-send-email-vijay.kilari@gmail.com> <55197005.7090408@linaro.org> <1427888815.2115.279.camel@citrix.com> <551BDE4C.9030109@citrix.com> <1427966007.4037.14.camel@citrix.com> <551D2298.2060302@citrix.com> <1427973539.4037.52.camel@citrix.com> <551D4888.1020309@gmail.com> <553F6271.4010308@citrix.com> <553FB23F.7090200@citrix.com> <5540C6D5.9020400@citrix.com> <5540DE16.4090900@citrix.com> <55411D1F.4090308@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Ian Campbell , Vijay Kilari , Prasun Kapoor , Vijaya Kumar K , Julien Grall , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , manish.jaggi@caviumnetworks.com List-Id: xen-devel@lists.xenproject.org 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 wrote: >>>> On Wed, Apr 29, 2015 at 7:05 PM, Julien Grall 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). 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. Regards, -- Julien Grall