On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias <edgar.igles...@gmail.com > wrote:
> On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote: > > On Wed, Feb 08, 2017 at 04:58:44PM +0000, Julien Grall wrote: > > > Hi Tamas, > > > > > > On 08/02/17 16:40, Tamas K Lengyel wrote: > > > >On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias > > > ><edgar.igles...@xilinx.com <mailto:edgar.igles...@xilinx.com>> wrote: > > > > On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote: > > > > > On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall < > julien.gr...@arm.com > > > > <mailto:julien.gr...@arm.com>> wrote: > > > > I considered this approach a bit but it has several problems IMO. > > > > These may not be unsolvable or even problems for monitoring but > > > > they do introduce complexity into the solution. > > > > > > > > 1. Some SMC calls may depend on the core they are issued from. > > > > If taking a detour to dom0, this becomes messy to guarantee. > > > > > > > > 2. Overall complexity increases very significantly and it becomes > > > > quite hard to follow/review how these calls get handled. > > > > In particular once you consider solving #1. > > > > > > > > 3. There are certain calls that perhaps not even dom0 should have > > > > direct access to. This means that Xen may need to filter some > of > > > > them anyway. > > > > > > > > Some examples may be: > > > > > > > > SMC calls: > > > > * To directly turn off or suspend cores > > > > * To turn off DDR or RAMs that Xen is using > > > > * To a solution specific Trusted OS pinned to a specific core > > > > * For PSCI > > > > * Etc > > > > > > > > I would prefer if we could find a way for monitoring to play > nicely > > > > with Xen implementing the SMC mediators. > > > > Perhaps we could allow calls that Xen consumes to be > monitored/inspected > > > > but not modified. Or there might be other ways. > > > > > > > > Best regards, > > > > Edgar > > > > > > > > > > > >Hi Edgar, > > > >certainly there are many cases where the system would become very > > > >complex when there is functionality like what you describe in the TZ > > > >that needs to be made accessible via SMC. The setup I described is > > > >experimental only, and the underlying assumption is that the TZ is > > > >working jointly with the monitor application (ie. both are aware of > each > > > >other). So it is really not intended to work with just any firmware. > > > > > > How do you expect TrustZone to work with the monitor application? If > you > > > think about modifying Trustzone, it seems a requirement difficult to > achieve > > > as some Trusted OS are proprietary or difficult to replace on a phone. > > > > > > > > > > >So I think for the sake of reducing complexity, having the monitor > > > >system be exclusive when enabled should make everyone's life simpler. > > > >Having a passive monitoring mode as you suggest is certainly an > option, > > > >although it should not be the only option, exclusive routing of SMCs > > > >through monitor applications should still be available to be > configured > > > >by the user. Since I really don't know of any usecases where passive > > > >monitoring of SMCs is required, I don't think we should go that route. > > > > > > I see the SMC trap similar to a register trap. The monitor app will > look at > > > the register value and potentially modify it. What would be the issue > to do > > > the same for SMC? > > > > Yes, I think this would work if we can keep the SMC processing on the > same > > core (after it's been accepted by monitor filters). If not accepted by > > filters, we'd just ignore the SMC processing and return registers > provided > > by the monitor (or something along those lines). > > > > > > > I think a such model would fit the requirement for everyone. The > monitor app > > > can filter if necessary, and Xen would handle the mediation between > multiple > > Any ideas on how we can support monitor filtering while at the same time > having Xen processing calls? How do we wait for a response from the monitor > and then (if allowed) issue the SMC from the right core? > There is a return path from the monitor application when the monitor request has been processed. See http://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=xen/common/vm_event.c;h=82ce8f1561384f6059c5ea152e3b0a55e63094a8;hb=HEAD#l402. We can do a call-down to an ARM specific handler that would then issue the SMC to the firmware if the monitor app specified that it is OK to do so. It is relatively easily to implement but I don't think it's a feature that anyone needs at the moment. > > Or we could make these approaches mutually exclusive. > That is what I would like to see. > 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. Tamas
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
