From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v7 14/28] xen/arm: ITS: Initialize physical ITS and export lpi support Date: Tue, 22 Sep 2015 11:44:42 +0100 Message-ID: <1442918682.10338.141.camel@citrix.com> References: <1442581755-2668-1-git-send-email-vijay.kilari@gmail.com> <1442581755-2668-15-git-send-email-vijay.kilari@gmail.com> <5600204C.6090506@citrix.com> <56012352.4060708@citrix.com> <1442916340.10338.130.camel@citrix.com> <56012D84.8090509@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56012D84.8090509@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall , Vijay Kilari Cc: Stefano Stabellini , Prasun Kapoor , Vijaya Kumar K , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , manish.jaggi@caviumnetworks.com List-Id: xen-devel@lists.xenproject.org On Tue, 2015-09-22 at 11:29 +0100, Julien Grall wrote: > > On 22/09/2015 11:05, Ian Campbell wrote: > > On Tue, 2015-09-22 at 10:45 +0100, Julien Grall wrote: > > > > > > On 22/09/2015 10:17, Vijay Kilari wrote: > > > > > Why do you need a command line option to enable/disable the > > > > > physical > > > > > ITS? > > > > > > > > I have added this to remove ITS support?. > > > > Did I misunderstood it. May be I have to avoid generating its dt > > > > node > > > > to disable its for dom0? > > > > > > My question is why do you want to let the user disabling the ITS > > > using > > > the command line? What's the use case? > > > > It's always useful to be able to nobble this sort of thing, either for > > debugging/development purposes or to allow users to workaround issues. > > This is can be done via the firmware table (see the property "status" in > the DT). This is not always trivial to override (think DTB provided by the UEFI firmware). > I see no advantage to use the command line for a such purpose, > mainly for the debugging/development point. > > Also what kind of workaround do you expect to be fixed by disabling ITS? Any bug relating to running on an ITS which a user trips over in the field. This isn't really any different from the myriad of options which already exist to disable particular hardware features lists in http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html (many of which are x86 specific, including I notice now msi=) > I know that it will disable all the PCI MSI in general. But should not > it be done with a PCI related parameter? Maybe there should be a PCI option as well, but disabling PCI MSI should inherit from the disabling of the ITS. Just as it should be disabled if the ITS isn't present at all. > > Assuming the switch is simple an reasonably self contained (and it really > > should be, since it should just be checked at start of day and then arrange > > to behave like no ITS is present) then I can't see why not to have it. > > I think that disabling the ITS is more complex than not using in Xen. > This will be tied with PCI passthrough very soon and we will have to > spread this decision everywhere. > > We would also have to remove everything related to ITS (i.e > msi-parent...) to the DT to avoid to pass an half-valid DT to DOM0. > Otherwise we may just not be able to boot or using PCI (even without > MSI). So this might fall into the "assuming the switch is simple" caveat which I mentioned, although I'm not convinced we need to go this far. We could equally well just mark the ITS node disabled and leave everything else alone. Ian.