Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Julien Grall <julien.grall@xxxxxxx>]

Hi Tamas,

Can you please try to configure your e-mail client to use '>' rather 
than '    '? It makes quite hard to read the e-mail.
On 08/02/2017 20:15, Tamas K Lengyel wrote:
> On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> <edgar.iglesias@xxxxxxxxx <mailto:edgar.iglesias@xxxxxxxxx>> wrote:
>     On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
>     If platform_hvc() consumes an SMC, it's considered part of the Xen API.
>     Visible but not filterable by a monitor.
>
>
>     Platforms can then dictate which SMC calls are better handled within
>     Xen and
>     which ones can be exposed to dom0 user-space.
>
>     In addition, there could be a hypercall to disable platform specific
>     handling
>     in Xen alltogether for a given guest. Then everything goes to dom0
>     user-space.
>
>     It's a little messy...
>
>
>
> That is messy and I would not want any SMCs reaching the firmware when
> the monitor application is in use. The monitor interface is disabled by
> default and there aren't any known usecases where the SMC has to reach
> both the firmware and the monitor application as well. So I think it is
> safe to just make the two things mutually exclusive.
If you look at the SMC Calling Convention [1] both HVC and SMC are 
considered a conduit for service call to the secure firmware or 
hypervisor. It would be up to the hypervisor deciding what to do.
Lets imagine the guest is deciding to use HVC to access the secure 
firmware (AFAIU this patch series is adding that), are you going to 
monitor all the HVCs (including hypercall)?
Similarly, non-modified baremetal app could use SMC to power on/off the 
vCPU (see PSCI spec). Will you emulate that in the monitor app?
So I think we need to be consistent across HVC and SMC call. And 
mutually exclusive does not sound right to me for HVC.
Cheers,

[1] 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028b/index.html

--
Julien Grall

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