On Wed, 2013-07-31 at 16:41 +0300, Andrii Anisov wrote:> Hello,
>
>
> The platform we work with (OMAP5) based on CortexA15 but has some
> specifics. One of such a specifics is so called ROM code, among all,
> it provides some vital functions for OSes.
Which vital function exactly?
It could be the case that it should be Xen which is calling these
functions directly and not dom0 at all.
For example consider PSCI. Only Xen should be able to control the real
physical processors (i.e. idle them, bring then up and down), but at the
same time it should (and does) provide its own PSCI interface to guests
(handled entirely within Xen) such that they can control their own
virtual processors using the same interfaces as bare metal.
In other cases it may make sense to allow dom0 to call the firmware (or,
more likely, for Xen to proxy the SMC calls on behalf of dom0) but we''d
need to discuss specific cases to know what the right answer is.
Ian.
> This functions are accessed by OSes with smc calls.
> With moving to the latest release I discovered that smc''s are not
> allowed for guests and are trapped by hypervisor. Currently I''ve
> allowed smc''s for guests.
> But future intention is to allow smc''s for Dom0, and somehow
> handle/proxy smc''s from DomU via Dom0. The intention is to have
> trusted Dom0 and do not allow DomU hack/crash the system. The first
> point is pretty simple.
> But I wonder how could I forward handling of the trapped smc to Dom0.
> It would be good to hear any thoughts or ideas about that from the
> people who are experienced in xen internals.
>
> Sincerely,
> Andrii Anisov.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel