[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls
On Tue, Aug 01, 2017 at 11:37:05AM +0100, Julien Grall wrote: > Hi Edgar, > > On 31/07/17 23:23, Edgar E. Iglesias wrote: > >On Thu, Feb 09, 2017 at 12:32:09PM -0700, Tamas K Lengyel wrote: > >>On Thu, Feb 9, 2017 at 11:43 AM, Stefano Stabellini > >><sstabellini@xxxxxxxxxx> wrote: > >>>On Thu, 9 Feb 2017, Tamas K Lengyel wrote: > >>>>On Thu, Feb 9, 2017 at 11:22 AM, Stefano Stabellini > >>>><sstabellini@xxxxxxxxxx> wrote: > >>>>>On Thu, 9 Feb 2017, Edgar E. Iglesias wrote: > >>>>>>On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote: > >>>>>>>On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote: > >>>>>>>>On Thu, 9 Feb 2017, Julien Grall wrote: > >>>>>>>>>On 08/02/2017 23:28, Tamas K Lengyel wrote: > >>>>>>>>>>On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall <julien.grall@xxxxxxx> > >>>>>>>>>>wrote: > >>>>>>>>>>>Hi Tamas, > > > >...... > > > >>>>In principle I have nothing against a command line option, but I don't > >>>>really follow how that would help. The monitor system is disabled by > >>>>default for all domains, so there is no problem with dom0 booting or > >>>>any other domain needing to access the firmware. You specifically have > >>>>to enable the monitoring for domains. Why is it a problem to have it > >>>>be exclusive for just those domains where it is enabled? > >>> > >>>I am suggesting this solution because I expect many use-cases for memory > >>>introspection that don't actually require any platform_hvc events to be > >>>monitored at all. On the other end, I expect that on platforms where > >>>platform_hvc is implemented, such as the ZynqMP, those calls are > >>>important and should be handled in Xen in most cases. > >>> > >>>Looking at the code, does monitor.privileged_call_enabled only cover > >>>SMC? Is monitor.privileged_call_enabled disabled by default? > >>>If so, monitor.privileged_call_enabled could be the tunable I was > >>>talking about. As long as enabling memory introspection doesn't > >>>automatically forward platform_hvc events to the monitor, I am fine with > >>>it. > >> > >>Yes, monitor.privileged_call_enabled only covers SMCs right now and it > >>is disabled by default. It has to be enabled specifically for a > >>domain. Memory introspection is separate from this, that is handled > >>by the mem_access system and it can be enabled separately from SMC > >>monitoring. > >> > >>As for hypercalls that get handled by Xen, I don't really need to > >>monitor those. If Xen would on the other hand go and call some > >>firmware as a result of the hypercall, I would need to be able to deny > >>that. So as long as XSM can be used to control HVC calls, that works > >>for me just fine too. > > > >Hi again! > > > >This was quite a while ago but I think we kind of ended up with > >monitor.privileged_call_enabled being a possible flag to conditionalize > >the forwarding of firmware calls or not. > > > >There are at least 3 cases to consider at the moment: > >1. Firmware calls over SMC (PSCI or other platform calls like EEMI) > >2. Firmware calls over HVC Handled by Xen (PSCI and XEN Hypercalls) > >3. Firmware calls over HVC Handled by platform specific code (e.g EEMI) > > > > > >For #1 Firmware calls over SMC: > >I've conditionalized all of it on monitor.privileged_call_enabled. > >It's either the monitor or the firmware call handling, they > >are mutually exclusive. Guests can still do PSCI over HVC. > > > >For #2, things work like today. This is PSCI and the Xen Hypercallsi over > >HVC. > > > >For #3, only platform code knows if the specific call will be handled > >in Xen completely or if it will result in some kind of SMC to lower layers. > >If monitor.privileged_call_enabled is on, I've made the ZynqMP > >implementation gracefully NACK any call that would result in an SMC > >issued by Xen. > > > >Are there any concerns around this? > > You may want to have a look at the discussion about SMC and Xen: > > https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg01226.html > > IIRC, the consensus is to exclusively forward SMC to the monitor if enabled: > > "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.". > Thanks Julien. I think it's better for EEMI to wait for the SMCC patches to go in and base the EEMI mediator on top of them. I'll hold back a little more with this. Cheers, Edgar _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |