All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC v1 0/6] zynqmp: Add forwarding of platform specific firmware calls
@ 2017-01-30 17:21 Edgar E. Iglesias
  2017-01-30 17:21 ` [RFC v1 1/6] xen/arm: traps: Reorder early overwrite of FID Edgar E. Iglesias
                   ` (5 more replies)
  0 siblings, 6 replies; 8+ messages in thread
From: Edgar E. Iglesias @ 2017-01-30 17:21 UTC (permalink / raw)
  To: xen-devel; +Cc: edgar.iglesias, julien.grall, sstabellini

From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>

The ZynqMP software stack has an extensive Firmware API.
Software at EL1 is increasingly dependant on this API. In fact,
a large set of use-cases for Linux already require access
to firmware. In a couple of months, we expect that most setups
will need it, so this is becoming somewhat urgent.

Services provided by the API, among other things include:
* Clock Management
* PHY Configuration
* Power Management
* FPGA configuration
* etc

Adding support for accessing firmware comes in two steps.

1. Allow the hw domain (dom0) to call into firmware. This enables
   all devices to work with PV setups.

2. Allow other guests to use the Firmware API. This will be needed
   to fully support Device pass-through.
   We cannot give un-supervised access to unprivileged guests, so
   the idea is to mediate these calls in Xen or preferably in
   dom0. Mediation mainly consists of ref-counting and filtering.

This RFC patch series implements step #1.

There are quite a few options on how to implement step #2, e.g:
1. Trap HVC/SMC calls from unpriv guests and handle them in dom0.
   This could be done in a user-space agent.
2. Add a PV protocol carrying these calls. This is similar to #1.
3. Add several generic PV protocols carrying a set of platform independent
   generic calls that get translated or mapped to firmware calls
   in dom0. E.g PV-Clock, PV-Power, PV-FPGA.
4. Others??

A benefit with #1 is that we could support unmodified bare-metal
guests. Such guests would continue to issue SMC calls from EL1 just as
if they were running without a hypervisor.

Best regards,
Edgar

Edgar E. Iglesias (6):
  xen/arm: traps: Reorder early overwrite of FID
  xen/arm: Introduce platform_hvc
  xen/arm: Allow platform_hvc to handle guest SMC calls
  xen/arm: Introduce call_smcc64
  xen/arm: zynqmp: Forward plaform specific firmware calls
  xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node

 xen/arch/arm/platform.c                |  8 ++++
 xen/arch/arm/platforms/xilinx-zynqmp.c | 67 +++++++++++++++++++++++++++++++---
 xen/arch/arm/traps.c                   | 13 ++++++-
 xen/include/asm-arm/platform.h         |  5 +++
 xen/include/asm-arm/processor.h        | 40 ++++++++++++++++++++
 5 files changed, 125 insertions(+), 8 deletions(-)

-- 
2.7.4


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-01-31  9:52 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-30 17:21 [RFC v1 0/6] zynqmp: Add forwarding of platform specific firmware calls Edgar E. Iglesias
2017-01-30 17:21 ` [RFC v1 1/6] xen/arm: traps: Reorder early overwrite of FID Edgar E. Iglesias
2017-01-30 17:21 ` [RFC v1 2/6] xen/arm: Introduce platform_hvc Edgar E. Iglesias
2017-01-30 17:21 ` [RFC v1 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls Edgar E. Iglesias
2017-01-30 17:21 ` [RFC v1 4/6] xen/arm: Introduce call_smcc64 Edgar E. Iglesias
2017-01-30 17:21 ` [RFC v1 5/6] xen/arm: zynqmp: Forward plaform specific firmware calls Edgar E. Iglesias
2017-01-31  9:52   ` Edgar E. Iglesias
2017-01-30 17:21 ` [RFC v1 6/6] xen/arm: zynqmp: Remove blacklist of ZynqMP's PM node Edgar E. Iglesias

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.