Re: [Xen-devel] [PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-03-09 at 13:14 +1000, Edgar E. Iglesias wrote:
> On Fri, Mar 06, 2015 at 09:44:16AM +0000, Ian Campbell wrote:
> > On Fri, 2015-03-06 at 11:31 +1000, Edgar E. Iglesias wrote:
> > > On Thu, Mar 05, 2015 at 04:50:15PM +0000, Ian Campbell wrote:
> > > > On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> > > > > From: "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxxx>
> > > > > 
> > > > > Adds support for the Cadence UART in Xilinx ZynqMP. The
> > > > > rest of the ZynqMP platform is discovered via device-tree.
> > > > 
> > > > Is it fully discovered and working out of the box? That would be ....
> > > > awesome!
> > > 
> > > Yes it would be awesome if we can keep it like that :-)
> > 
> > I suppose you are seeing the "WARNING: Unrecognized/unsupported device
> > tree compatible list" message?
> 
> Yes, thats right.
> 
> > 
> > I wonder if we should either remove or tone down that warning, now that
> > we have a platform which genuinely doesn't require any platform specific
> > code. I think we probably want to say something so in bug reports we
> > know what is happening, maybe just something like "Platform: Generic
> > System".
> 
> 
> Sounds good to me, I can send a follow up patch for that.

I've seen it and put it in my (rather long) list of things to look at,
thanks!

> > > It's possible that we will need to add platform code in the future
> > > as we test out more features. In particular we'll likely need to do
> > > something around power/clock management.
> > 
> > Yes, this is something of an open problem for us, and one which I'm
> > unsure how to solve without some platform specific code in each case.
> > 
> > Most power/clock management should be deferred to the h/w domain which
> > is managing the I/O peripherals (likely dom0) but we need some way to
> > filter its activities to keep e.g. the CPU and UART (or in reality any
> > h/w block Xen itself is using, which isn't many fortunately) clocks on.
> > 
> > http://bugs.xenproject.org/xen/bug/45 is a related bug.
> 
> Very interesting, thanks.
> 
> There is another dimenson to the power/clock problem. The ZynqMP has a
> runtime programmable TrustZone system partitioning block in the interconnect.
> Something similar to ARMs TZASC. This allows you to program the
> Secure/Non-Secure device partitioning for example at boot time.
> Depending on the split, it might not be OK to give NS Linux or even
> NS XEN direct access to the power/clock configuration registers.
> I.e, we don't want NS Linux to power down a device currently in use
> by a Trusted OS.
> 
> What we are considering is an extension to the PSCI approach, an SMC
> interface to expose the low level power/clock operations.
> 
> Linux can still have all the smart control logic for Power Management
> but an SMC interface would allow the various layers (XEN EL2,
> ARM trusted firmware EL3) to filter or emulate the various requests.
> 
> Ofcourse, the devil will be in the details...
> 
> It would be interesting to hear your and others thought on that kind
> of approach.

It's an interesting approach, and not without precedent AIUI. And I
think you are right to make the link between NS.EL1 vs NS.EL2 and NS.EL*
vs S.EL*, they are very similar problems in the end.

We've not actually come across such a platform yet, but I think it is
inevitable that eventually we will need to trap platform specific SMC
calls from dom0 on some platform and decide what to do with them on a
per-operation basis (quash them, emulate them, forward them to S world,
etc).

If such an interface was available for power/clock then I think that
would be preferable to trapping and emulating register writes and
white/blacklisting individual register bits etc.

Best of all, I think, at least from Xen's PoV, would be if there was
some PSCI-like overall standard which all vendors used for this, such
that Xen could grow a more generic framework for SMC traps of this type.

As you say, devil is in the details!

Ian.


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