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 15.05.2015 21:44, Konrad Rzeszutek Wilk 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 15.05.2015 21:44, Konrad Rzeszutek Wilk wrote:
[...]
## Hypercalls
We will employ the sub operations of the
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
We will employ the sub operations of the system management hyperca
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
We will employ the sub operations of the system management hypercall
(sysctl).
There are to be four sub-operations:
* upload the
On 06/12/2015 12:39 PM, Martin Pohlack wrote:
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 uploa
On Fri, Jun 12, 2015 at 12:09:24PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 12, 2015 at 04:31:12PM +0200, Martin Pohlack wrote:
> > 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 Rze
On Fri, Jun 12, 2015 at 08:36:29PM +0200, Martin Pohlack wrote:
> 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 tak
On Fri, Jun 12, 2015 at 07:31:25PM +0200, Martin Pohlack wrote:
> 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
> >> will
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.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 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 - which means if
> >>> we were to try to cancel it (say
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 - which means if
>>> we were to try to cancel it (say it had run for an hour and still
>>> could not patch it)- we have to add
On Fri, Jun 12, 2015 at 04:31:12PM +0200, Martin Pohlack wrote:
> 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 th
>>> 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_machine-like barrier as part of a relevant hyperc
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 management hypercall
>>> (sysctl).
>>> There a
On Fri, Jun 12, 2015 at 01:51:08PM +0200, Martin Pohlack wrote:
> On 08.06.2015 17:19, Konrad Rzeszutek Wilk wrote:q
Heh - ":q", well now I know what editor camp you are in :-)
> [...]
> >>> There is a nice part of the old code check - you
> >>> can check (and deal with) patching an already patch
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 management hypercall
> > (sysctl).
> > There are to be four sub-operations:
> >
> > * upload the
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 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
. snip ..
> >> * You may need support for adapting or augmenting exception tables if
> >> patching such code is desired (it probably is). Hotpatches may need
> >> to bring their own small exception tables (similar to how Linux
> >> modules support this). If you don't plan on supporting hotp
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 design at Linux
>> Plumbers Conference
>>> On 08.06.15 at 10:34, wrote:
> 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 identification h
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 identification hard. Sometimes, static symbols
>>> si
>>> On 05.06.15 at 18:00, wrote:
> On Fri, Jun 05, 2015 at 04:16:59PM +0100, Jan Beulich wrote:
>> >>> On 05.06.15 at 16:49, wrote:
>> > On Mon, May 18, 2015 at 01:41:34PM +0100, Jan Beulich wrote:
>> >> >>> On 15.05.15 at 21:44, wrote:
>> >> A general remark: Having worked on ELF on different o
On Fri, Jun 05, 2015 at 04:16:59PM +0100, Jan Beulich wrote:
> >>> On 05.06.15 at 16:49, wrote:
> > On Mon, May 18, 2015 at 01:41:34PM +0100, Jan Beulich wrote:
> >> >>> On 15.05.15 at 21:44, wrote:
> >> > As such having the payload in an ELF file is the sensible way. We would
> >> > be
> >> > c
>>> 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 identification hard. Sometimes, static symbols
>> simply have the same name in C files, sometimes
>>> On 05.06.15 at 16:49, wrote:
> On Mon, May 18, 2015 at 01:41:34PM +0100, Jan Beulich wrote:
>> >>> On 15.05.15 at 21:44, wrote:
>> > As such having the payload in an ELF file is the sensible way. We would be
>> > carrying the various set of structures (and data) in the ELF sections under
>> >
On 05/06/15 16:00, Konrad Rzeszutek Wilk wrote:
>> As you discussed, if you allocate hotpatch memory withing +-2GB of the
>> > patch location, no further trampoline indirection is required, a
>> > 5-byte JMP does the trick on x86. We found that to be sufficient in
>> > our experiments.
> And worst
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 design at Linux
> Plumbers Conference 2014 in Düsseldorf, slides are here:
>
> http://www.linuxplumbersconf.net/2014/ocw//sys
On Mon, May 18, 2015 at 08:54:22PM +0800, Liuqiming (John) wrote:
> Hi Konrad,
>
> Will this design include hotpatch build tools chain?
Yes, that is certainly the idea.
> Such as how these .xplice_ section are created? How to handle xen symbols
> when creating hotpatch elf file?
Right now I am
On Mon, May 18, 2015 at 01:41:34PM +0100, Jan Beulich wrote:
> >>> On 15.05.15 at 21:44, wrote:
> > As such having the payload in an ELF file is the sensible way. We would be
> > carrying the various set of structures (and data) in the ELF sections under
> > different names and with definitions. T
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
Adding Don Slutz as he requested to be added
Lars
On 15/05/2015 20:44, "Konrad Rzeszutek Wilk"
wrote:
>Hey!
>
>During the Xen Hacka^H^H^H^HProject Summit? we chatted about live-patching
>the hypervisor. We sketched out how it could be done, and brainstormed
>some of the problems.
>
>I took that
On Mon, May 18, 2015 at 08:54:22PM +0800, Liuqiming (John) wrote:
> Hi Konrad,
>
> Will this design include hotpatch build tools chain?
> Such as how these .xplice_ section are created?
> How to handle xen symbols when creating hotpatch elf file?
No, this is not a main goal of this project. Howeve
Hi Konrad,
Will this design include hotpatch build tools chain?
Such as how these .xplice_ section are created? How to handle xen symbols when
creating hotpatch elf file?
On 2015/5/16 3:44, Konrad Rzeszutek Wilk wrote:
Hey!
During the Xen Hacka^H^H^H^HProject Summit? we chatted about live-pat
>>> On 15.05.15 at 21:44, wrote:
> As such having the payload in an ELF file is the sensible way. We would be
> carrying the various set of structures (and data) in the ELF sections under
> different names and with definitions. The prefix for the ELF section name
> would always be: *.xsplice_*
>
Hey!
During the Xen Hacka^H^H^H^HProject Summit? we chatted about live-patching
the hypervisor. We sketched out how it could be done, and brainstormed
some of the problems.
I took that and wrote an design - which is very much RFC. The design is
laid out in two sections - the format of the ELF pay
37 matches
Mail list logo
