On 06.04.2016 04:42, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 01, 2016 at 09:50:31AM -0600, Jan Beulich wrote:
> On 24.03.16 at 21:00, wrote:
>>> From: Ross Lagerwall
>>>
>>> Add hook functions which run during patch apply and patch revert.
>>> Hook functions are used by xsplice payloads to
On 27.04.2016 05:39, Konrad Rzeszutek Wilk wrote:
[...]
> +/* "Mask" NMIs. */
> +arch_xsplice_mask();
You mask here ...
> +barrier(); /* MUST do it after get_cpu_maps. */
> +cpus = num_online_cpus() - 1;
> +
> +if ( cpus )
> +{
> +dprint
On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
On 12.10.16 at 15:23, wrote:
And then - how is all of this supposed to be working in conjucntion
with live patching, where the patch may have been created by yet
another compiler ver
On 12.10.2016 18:21, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 12, 2016 at 04:17:57PM +0200, Martin Pohlack wrote:
On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
On 12.10.16 at 15:23, wrote:
And then - how is all of this
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 03.11.2015 19:16, Ross Lagerwall wrote:
> 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 all the
> return-to-guest paths to check for work to do and execute i
On 03.11.2015 19:16, Ross Lagerwall wrote:
> +#ifdef CONFIG_X86
> +unsigned long search_module_extables(unsigned long addr)
> +{
> +struct payload *data;
> +unsigned long ret;
> +
> +/* No locking since this list is only ever changed during apply or revert
> + * context. */
How do
On 05.06.2015 17:27, Jan Beulich wrote:
>>>> On 05.06.15 at 17:00, wrote:
>> On Wed, May 20, 2015 at 05:11:20PM +0200, Martin Pohlack wrote:
>>> * Xen as it is now, has a couple of non-unique symbol names which will
>>> make runtime symbol identificat
Hi,
some inline comments.
On 05.06.2015 17:00, Konrad Rzeszutek Wilk wrote:
> On Wed, May 20, 2015 at 05:11:20PM +0200, Martin Pohlack wrote:
>> Hi,
>>
>> this looks very interesting.
>
> Thank you!
>>
>> I have talked about an experimental Xen hotpatching
On 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote:
[...]
> ## Hypercalls
>
> We will employ the sub operations of the system management hypercall (sysctl).
> There are to be four sub-operations:
>
> * upload the payloads.
> * listing of payloads summary uploaded and their state.
> * getting an
On 08.06.2015 17:19, Konrad Rzeszutek Wilk wrote:q
[...]
>>> There is a nice part of the old code check - you
>>> can check (and deal with) patching an already patched code.
>>> As in, if the payload was configured to be applied on top of an already
>>> patched function it would patch nicely. But i
On 12.06.2015 16:03, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 12, 2015 at 01:39:05PM +0200, Martin Pohlack wrote:
>> On 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote:
>> [...]
>>> ## Hypercalls
>>>
>>> We will employ the sub operations of the system man
On 12.06.2015 16:43, Jan Beulich wrote:
On 12.06.15 at 16:31, wrote:
>> The 1ms is just a random number. I would actually suggest to allow a
>> sysadmin or hotpatch management tooling to specify how long one is
>> willing to potentially block the whole machine when waiting for a
>> stop_mach
On 12.06.2015 18:39, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 12, 2015 at 05:17:13PM +0100, Andrew Cooper wrote:
>> On 12/06/15 17:09, Konrad Rzeszutek Wilk wrote:
>>>
> The _GET_STATUS does not enforce this and can take longer giving us
> more breathing room - and also unbounded time - w
On 12.02.2016 19:05, Konrad Rzeszutek Wilk wrote:
> From: Ross Lagerwall
>
> Shadow variables are a piece of infrastructure to be used by xsplice
> modules. They are used to attach a new piece of data to an existing
> structure in memory.
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/common/Ma
On 12.02.2016 19:05, Konrad Rzeszutek Wilk wrote:
> From: Ross Lagerwall
>
> Shadow variables are a piece of infrastructure to be used by xsplice
> modules. They are used to attach a new piece of data to an existing
> structure in memory.
>
> Signed-off-by: Ross Lagerwall
> ---
> xen/common/Ma
Hi,
this looks very interesting.
I have talked about an experimental Xen hotpatching design at Linux
Plumbers Conference 2014 in Düsseldorf, slides are here:
http://www.linuxplumbersconf.net/2014/ocw//system/presentations/2421/original/xen_hotpatching-2014-10-16.pdf
and would like to share a co
On 14.01.2016 09:58, Jan Beulich wrote:
On 14.01.16 at 03:02, wrote:
Or are you suggesting that perhaps the kernel should at boot time
print the build-id (like it does the changset)?
>>>
>>> Perhaps, albeit to me that's a bit orthogonal to being able to find out
>>> the build ID for
On 17.09.2015 00:31, Andrew Cooper wrote:
> On 16/09/2015 22:59, Konrad Rzeszutek Wilk wrote:
>> On September 16, 2015 5:41:26 PM EDT, Andrew Cooper
>> wrote:
>>> On 16/09/2015 22:01, Konrad Rzeszutek Wilk wrote:
>>>> From: Martin Pohlack
>>&g
On 27.07.2015 21:20, Konrad Rzeszutek Wilk wrote:
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> tools/libxc/xc_private.c | 3 +++
> tools/misc/xen-xsplice.c | 25 +
> xen/common/kernel.c | 11 +++
> xen/common/version.c | 5 +
> xen/
Hi,
Another high-level point to think about is how we want to handle inlined
__LINE__ references. This problem is related to hotpatch construction
and potentially has influence on the design of the hotpatching
infrastructure in Xen.
Let me try to explain the problem:
We have file1.c with functi
On 05.08.2015 10:58, Andrew Cooper wrote:
> On 05/08/15 09:50, Martin Pohlack wrote:
>> On 27.07.2015 21:20, Konrad Rzeszutek Wilk wrote:
>>> Signed-off-by: Konrad Rzeszutek Wilk
>>> ---
>>> tools/libxc/xc_private.c | 3 +++
&g
Sending again without MUA-mangled patch.
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-dev
Todo:
* Should be moved to sysctl to only allow Dom0 access
* Maybe convert to binary transport to userland instead of printable form
* use ld to actually embed the build ID
* convert to textual representation in hypervisor and report in
printable form
Signed-off-by: Martin Pohlack
ce: Add hook for build_id
was:
------
>> Martin Pohlack:
>> We should not expose the build_id to normal guests, but only to Dom0.
>>
>> A build_id uniquely identifies a specific build and I don't see how that
>> information would be re
;>
>>> Because of?
>>
>> The discussion in this thread:
>>
>> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
>>
>> was:
>> --
>>>> Martin Pohlack:
>&g
On 09.10.2015 04:56, Konrad Rzeszutek Wilk wrote:
> @@ -367,6 +368,35 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg,
> if ( copy_to_guest(arg, saved_cmdline, ARRAY_SIZE(saved_cmdline)) )
> return -EFAULT;
> return 0;
> +
> +case XENVER_build_id:
On 16.09.2015 23:01, Konrad Rzeszutek Wilk wrote:
[...]
> +### xsplice_patch
> +
> +This structure has the binary code (or data) to be patched. Depending on the
> +type it can either an inline patch (data or text) or require an relocation
> +change (which requires a trampoline). Naturally it also
On 26.10.2015 12:51, Jan Beulich wrote:
> To make it possible to tell apart the static symbols therein, use their
> object file names instead of their source ones.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Introduce __OBJECT_FILE__.
>
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -42,10 +42,10
On 06.10.2015 14:57, Ross Lagerwall wrote:
> On 09/16/2015 10:01 PM, Konrad Rzeszutek Wilk wrote:
>> +### xSplice interdependencies
>> +
>> +xSplice patches interdependencies are tricky.
>> +
>> +There are the ways this can be addressed:
>> + * A single large patch that subsumes and replaces all pr
On 09.10.2015 11:31, Ian Campbell wrote:
> On Thu, 2015-10-08 at 22:56 -0400, Konrad Rzeszutek Wilk wrote:
>> The XENVER_[compile_info|changeset|commandline] are now
>> guarded by an XSM check.
>
> I can guess, but please explain/justify why this is the case for these
> here.
>
>> The rest: XENVE
On 09.10.2015 04:56, Konrad Rzeszutek Wilk wrote:
> The XENVER_[compile_info|changeset|commandline] are now
> guarded by an XSM check.
>
> The rest: XENVER_[version|extraversion|capabilities|
> parameters|get_features|page_size|guest_handle] behave
> as before (no XSM check).
I think extraversion
On 29.10.2015 17:55, Ross Lagerwall wrote:
> On 10/27/2015 12:05 PM, Ross Lagerwall wrote:
>> On 06/12/2015 12:39 PM, Martin Pohlack wrote:
>>> On 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote:
>>> [...]
>>>> ## Hypercalls
>>>>
>>>
On 30.10.2015 15:03, Ross Lagerwall wrote:
> On 10/30/2015 10:39 AM, Martin Pohlack wrote:
>> On 29.10.2015 17:55, Ross Lagerwall wrote:
>>> On 10/27/2015 12:05 PM, Ross Lagerwall wrote:
>>>> On 06/12/2015 12:39 PM, Martin Pohlack wrote:
>>>>> On
: code
inspection of generated hotpatches, testing, and by making unloading
a very special and exceptional operation.
... and more inline comments below.
Regards,
Martin Pohlack
On 06.07.2015 22:26, Konrad Rzeszutek Wilk wrote:
> Since RFC v2
> [http://lists.xen.org/archives/html/xen-deve
35 matches
Mail list logo
