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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

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

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