From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH v4 2/3] arm: export platform_op XENPF_settime64 Date: Tue, 24 Nov 2015 12:00:04 -0500 Message-ID: <56549794.9070803@tycho.nsa.gov> References: <1447350364-22923-2-git-send-email-stefano.stabellini@eu.citrix.com> <1447679291.27871.81.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1447679291.27871.81.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Stefano Stabellini , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 > > Acked-by: Ian Campbell > > 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. > 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. -- Daniel De Graaf National Security Agency