Re: [PATCH v6 10/24] xsplice: Implement support for applying/reverting/replacing patches.

From: Julien Grall <julien.grall@arm.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xenproject.org, konrad@kernel.org,
	ross.lagerwall@citrix.com, mpohlack@amazon.de,
	sasha.levin@oracle.com, andrew.cooper3@citrix.com
Cc: Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v6 10/24] xsplice: Implement support for applying/reverting/replacing patches.
Date: Fri, 8 Apr 2016 16:36:50 +0100	[thread overview]
Message-ID: <5707D012.6050609@arm.com> (raw)
In-Reply-To: <1460000983-28170-11-git-send-email-konrad.wilk@oracle.com>

Hi Konrad,

On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote:
> From: Ross Lagerwall <ross.lagerwall@citrix.com>
>
> Implement support for the apply, revert and replace actions.
>
> To perform and action on a payload, the hypercall sets up a data
> structure to schedule the work.  A hook is added in the reset_stack_and_jump
> to check for work and execute it if needed (specifically we check an
> per-cpu flag to make this as quick as possible).
>
> In this way, patches can be applied with all CPUs idle and without
> stacks.  The first CPU to run check_for_xsplice_work() becomes the
> master and triggers a reschedule softirq to trigger all the other CPUs
> to enter check_for_xsplice_work() with no stack.  Once all CPUs
> have rendezvoused, all CPUs disable IRQs and NMIs are ignored.
> The system is then quiscient and the master performs the action.
> After this, all CPUs enable IRQs and NMIs are re-enabled.
>
> Note that it is unsafe to patch do_nmi and the xSplice internal functions.
> Patching functions on NMI/MCE path is liable to end in disaster.
> This is not addressed in this patch and is mentioned in the
> design doc as a further TODO.
>
> The action to perform is one of:
> - APPLY: For each function in the module, store the first 5 bytes of the
>    old function and replace it with a jump to the new function.
> - REVERT: Copy the previously stored bytes into the first 5 bytes of the
>    old function.
> - REPLACE: Revert each applied module and then apply the new module.
>
> To prevent a deadlock with any other barrier in the system, the master
> will wait for up to 30ms before timing out.
> Measurements found that the patch application to take about 100 μs on a
> 72 CPU system, whether idle or fully loaded.
>
> We also add an BUILD_ON to make sure that the size of the structure
> of the payload is not inadvertly changed and that the offsets are
> correct on both 32 and 64-bit hypervisor (ARM32 and ARM64).
>
> Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

For the ARM bits:

Acked-by: Julien Grall <julien.grall@arm.com>

Regards,

-- 
Julien Grall

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