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

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Tue, Feb 14, 2017 at 12:11 PM, Stefano Stabellini
<sstabellini@xxxxxxxxxx> 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.
>
> 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.

Correct, calls that are emulated by Xen itself don't need to be
forwarded to the monitor app.

Tamas

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