Re: [Xen-devel] [PATCH v7 14/28] xen/arm: ITS: Initialize physical ITS and export lpi support

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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=<boolean>)

> 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.

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