On Tue, 2015-11-24 at 12:00 -0500, Daniel De Graaf wrote:
> On 16/11/15 08:08, Ian Campbell wrote:
> > On Thu, 2015-11-12 at 17:46 +0000, Stefano Stabellini wrote:
> > > Call update_domain_wallclock_time at domain initialization.
> > > Set time_offset_seconds to the number of seconds between physical
> > > boot
> > > and domain initialization: it is going to be used to get/set the
> > > wallclock time.
> > > Add time_offset_seconds to system_time when before calling
> > > do_settime,
> > > so that system_time actually accounts for all the time in nsec
> > > between
> > > machine boot and when the wallclock was set.
> > > 
> > > Expose xsm_platform_op to ARM.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
> > 
> > Acked-by: Ian Campbell <ian.campb...@citrix.com>
> > 
> > An aside:[...]
> > @@ -1332,6 +1332,75 @@ static int flask_deassign_dtdevice(struct domain
> > > *d, const char *dtpath)
> > >   }
> > >   #endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE */
> > > 
> > > +static int flask_platform_op(uint32_t op)
> > > +{
> > > +    switch ( op )
> > > +    {
> > > +#ifdef CONFIG_X86
> > > +    /* These operations have their own XSM hooks */
> > > +    case XENPF_cpu_online:
> > > +    case XENPF_cpu_offline:
> > > +    case XENPF_cpu_hotadd:
> > > +    case XENPF_mem_hotadd:
> > > +        return 0;
> > 
> > Should this not then be an error (e.g. fail closed)?
> 
> During the invocation of these operations, two XSM hooks are called: this
> one (from above the switch) and the individual hook (inside the switch).
> This hook needs to allow access so that the more detailed hook is called.

I see, thanks for the explanation.

> > Also, although only implemented today for x86 they don't seem
> > inherently
> > any more x86 specific than many of the other things below, so maybe the
> > ifdef could be ditched?
> 
> The #ifdef is there mostly as a failsafe reminder to ensure that the
> implementation for other architectures actually calls the same XSM hooks
> that the x86 version does.

OK.

Ian.


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

Reply via email to