On 03.11.2015 19:15, Ross Lagerwall wrote:
[...]
> +struct xen_sysctl_xsplice_summary {
> +xen_xsplice_id_tid; /* IN, the name of the payload. */
I still feel a bit confused about the ID vs. name thingy. IMHO, each
payload should have a name (easily readable by a human, like
"
On 11/03/2015 06:15 PM, Ross Lagerwall wrote:
From: Konrad Rzeszutek Wilk
snip
+## Patching code
+
+The first mechanism to patch that comes in mind is in-place replacement.
+That is replace the affected code with new code. Unfortunately the x86
+ISA is variable size which places limits on how
On Thu, Nov 05, 2015 at 10:49:51AM +, Ross Lagerwall wrote:
> On 11/04/2015 09:10 PM, Konrad Rzeszutek Wilk wrote:
> snip
> >>+The payload **MUST** contain enough data to allow us to apply the update
> >>+and also safely reverse it. As such we **MUST** know:
> >>+
> >>+ * The locations in memor
On 11/04/2015 09:10 PM, Konrad Rzeszutek Wilk wrote:
snip
+The payload **MUST** contain enough data to allow us to apply the update
+and also safely reverse it. As such we **MUST** know:
+
+ * The locations in memory to be patched. This can be determined dynamically
+ via symbols or via virtual
On Tue, Nov 03, 2015 at 06:15:58PM +, Ross Lagerwall wrote:
> From: Konrad Rzeszutek Wilk
>
> A mechanism is required to binarily patch the running hypervisor with new
> opcodes that have come about due to primarily security updates.
>
> This document describes the design of the API that wou
From: Konrad Rzeszutek Wilk
A mechanism is required to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.
This document describes the design of the API that would allow us to
upload to the hypervisor binary patches.
This document has b
