[Xen-devel] [RFC v2 0/6] zynqmp: Add forwarding of platform specific firmware calls

["Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx>]

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

The ZynqMP software stack has an extensive Firmware API based on EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
https://www.xilinx.com/support/documentation/user_guides/ug1199-zynq-power-management.pdf

Software at EL1 is increasingly dependant on this API. In fact,
a large set of use-cases for Linux already require access to firmware.

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

Adding support for accessing firmware can be done 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 in dom0.
   Mediation mainly consists of verfifying access to calls,
   modifying calls and sometimes blocking them.

This patch series implements step #2.

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.
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. Same as #1 but doing it all in Xen.
5. Others??

A benefit with #1 and #4 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.

This patch series implements step #2 according to option #4.

EEMI has 3 kinds of resources it operates on.
1. Nodes (can be anything, a device, a CPU, a bus, a PLL)
2. Reset lines
3. MMIO accesses (i.e direct register access)

This implementation relies on the assumption that these
can be associated to a real device with some kind of
register area controlling it. If a guest has access to these
registers (e.g by being granted access via iomem), the
guest is allowed to control the node.

So, we map Nodes and rest-lines to memory addresses and check if
the guest issuing the call has access the device's control regs.

For direct MMIO calls, we map addresses and bitfields within registers
into nodes that get checked for guest ownership.

Guests are only allowed to power up/down and reset devices that are
in their control.

Certain calls, nodes and registers cannot be mapped (yet) to guests.
These fall mostly under dom0's control. A few calls are never allowed
(e.g turning off the current CPU or powering off DDR).

Any feedback would be much appreciated.

Thanks and Best regards!
Edgar

ChangeLog:

v1 -> v2:
* Advance PC after successfully processing an SMC
* Add implementation of a ZynqMP EEMI Mediator

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/Makefile                    |   1 +
 xen/arch/arm/platforms/xilinx-zynqmp-eemi.c        | 794 +++++++++++++++++++++
 xen/arch/arm/platforms/xilinx-zynqmp.c             |  22 +-
 xen/arch/arm/traps.c                               |  15 +-
 xen/include/asm-arm/platform.h                     |   5 +
 xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 337 +++++++++
 xen/include/asm-arm/platforms/xilinx-zynqmp-mm.h   | 284 ++++++++
 xen/include/asm-arm/processor.h                    |  40 ++
 9 files changed, 1498 insertions(+), 8 deletions(-)
 create mode 100644 xen/arch/arm/platforms/xilinx-zynqmp-eemi.c
 create mode 100644 xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
 create mode 100644 xen/include/asm-arm/platforms/xilinx-zynqmp-mm.h

-- 
2.7.4


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