[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [ARM] SMC (and HVC) handling in hypervisor

Hi Stefano,

On 14/02/17 19:11, Stefano Stabellini wrote:
On Tue, 14 Feb 2017, Julien Grall wrote:
  10. Domains on which the monitor privileged call feature is enabled
  (which is by default disabled for all domains) should not be able to
  issue firmware calls via SMCs/HVCs so that such calls reach the
  firmware directly. Xen should not bounce such calls to the firmware on
  behalf of the domain. Xen should not alter the state of the domain
  automatically (ie. incrementing PC). These calls should be exclusively
  transfered to the monitor subscriber for further processing.
  Hypercalls, virtual PSCI calls, virtual CPU services calls and virtual
  ARM architecture service calls remain unaffected.

Does that work for you?

It works iff hypercalls, virtual psci calls and virtual CPU services
can be denied with XSM. If that's not the case, then no, in that case
all those HVC calls that would be bounced to the firmware need to be
hooked into the monitor system as well. Ideally as soon as they are
being introduced to the Xen codebase.

I don't think we have XSM hooks for all of those today, but I think
everybody would agree that it is be a good idea to have them.

I disagree here. If you add XSM hook in vPSCI, it means you will allow the
user to deny CPU bring up. In this case, what is the point to have a guest
with multiple CPUs?

Regarding forwarding to the monitor app, this is very similar to MMIO region
emulated by either Xen or QEMU (in x86 case) they cannot be forwarded. Are you
going to add XSM in the MMIO emulation too? Are you going to emulate the
vITS/vGIC/vUART/pl011 in the monitor app?

Let's talk about your two concerns separately, because they are
separate points.

I won't go into the merits of the comparison between firmware calls and
x86 MMIO region emulation. However, I think that forwarding firmware
calls events to the monitor is fine. It allows new potential use-cases
for Xen, without affecting any of the current use-cases, given that
firmware calls forwarding would need to be enabled separately.

In regards to XSM hooks for vPSCI, after looking at the code, it is true
that there aren't any XSM hooks even for the corresponding PV vcpu_op
hypercalls (used for PV guests on x86). Introducing them might not be as
obvious as I thought. But I don't think we actually need XSM for this.

Firstly, we need to distinguish between SMC/HVC calls that result in
platform and TEE calls (the main topic of this thread), and SMC/HVC
calls that result in virtual PSCI CPU operations and Xen hypercalls
(do_trap_psci and do_trap_hypercall). The first set of calls is bounced
to the firmware, while the second set of calls is emulated/virtualized.

Agree here. Although, I think we would need a finer grain in the future to allow services (see Table 6-1 in the SMC convention) to be either forwarded to the monitor, emulated, or forwarded to the host secure firmware.

Clearly, the first set of calls would need to be forwarded to the
monitor. I don't think that the second set of calls need to be forwarded
or filtered, because they actually do not result in any firmware calls.
Once the user enables "firmware calls forwarding to the monitor", we
could just leave the virtual PSCI cpu ops and hypercalls implemented as
they are today. We just need to write down in a document what SMC/HVC
calls get forwarded to the monitor once the user enabled the appropriate

Sounds good to me.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.