[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2] xSplice design
On Fri, Jun 05, 2015 at 04:16:59PM +0100, Jan Beulich wrote: > >>> On 05.06.15 at 16:49, <konrad.wilk@xxxxxxxxxx> wrote: > > On Mon, May 18, 2015 at 01:41:34PM +0100, Jan Beulich wrote: > >> >>> On 15.05.15 at 21:44, <konrad.wilk@xxxxxxxxxx> 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_* > >> > > >> > Note that every structure has padding. This is added so that the > >> > hypervisor > >> > can re-use those fields as it sees fit. > >> > > >> > There are five sections *.xsplice_* sections: > >> > >> A general remark: Having worked on ELF on different occasions, > >> UNIX'es (and hence Linux'es) use of section names to identify the > >> sections' purposes is pretty contrary to ELF's original intentions. > >> Section types (and architecture as well as OS extensions to them) > >> exist for a reason. Of course from the following sections it's not > >> really clear in how far you intended this to be done. If you did > >> and just didn't explicitly say so, pointing out that relations > >> between sections should then also be expressed suitably via ELF > >> mechanisms (sh_link, sh_info) would then be unnecessary too. If > >> you didn't, then I'd strongly suggest switching to a formally more > >> correct model, which would then include specifying section types > >> and section attributes (and optional other relevant aspects) > >> along with their (then no longer mandatory) names. > > > > > > Something like: > > http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter7-1.html > > Yes, the SHT_SUNW_* ones are examples of what I mean. > > > With (for example) an pointer to a specific section: > > http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter7-28.html#scrolltoc > > > > ? > > Not sure what part of that page you mean to refer to. The whole page - with the: typedef struct { Elf32_Word c_tag; union { Elf32_Word c_val; Elf32_Addr c_ptr; } c_un; } Elf32_Cap; .. and such. > > >> > * `.bss` section for the new code (function) > >> > * `.data` and `.data.read_mostly` section for the new and old code > >> > (function) > >> > * `.rodata` section for the new and old code (function). > >> > > >> > In short the *.xsplice_* sections represent various structures and the > >> > ELF provides the mechanism to glue it all together when loaded in memory. > >> > >> As per above - I think ELF can do this in a more explicit way. Of > >> course that would imply sticking to strictly ELF types in the structure > >> definitions below. That would in turn have the advantage of > >> expressing e.g. "const char *" references to strings by section > >> offsets into a specified string section, reducing (with the ultimate > >> goal of eliminating) the need for processing relocations on the > >> ELF object (possible references to "external symbols" left aside for > >> the moment). > > > > Do you think that going that way would be too complex for this design? > > Folks have expressed that perhaps I went overboard with this ELF and > > should have just stuck with structures and just mention that it is > > in an ELF file? > > I think it should be done either completely ELF-agnostic (with ELF > just happening the container to convey the data) or fully ELF- > compliant. Let me do it ELF agnostic for right now and focus on the structures. If it becomes to difficult to understand then I can look at converting the whole thing to be ELF compliant. > > >> > #define XSPLICE_HOWTO_RELOC_TIME 3 /* __TIME__ type chnage. */ > >> > >> Assuming the former is DATE - what do you foresee date/time > >> kinds of changes to be good for? > > > > In case we have source code which uses __DATE__ and the binary patch > > modifies it - we would need to sort out other users of the __DATE__ > > and make sure that they are not affected (or perhaps they should be). > > And how is this different from arbitrary other string literals? They are exactly the same. Will coalesce them. > > >> > #define XSPLICE_HOWTO_BUG 4 /* BUG_ON being replaced.*/ > >> > #define XSPLICE_HOWTO_EXTABLE 5 /* exception_table change. */ > >> > #define XSPLICE_HOWTO_SYMBOL 6 /* change in symbol table. */ > >> > >> For none of these I really understand their purpose. > > > > This is to help the hypervisor to figure out which of the lookup > > mechanisms to use to find the relevant section. As in if we need > > to update (as part of the patch) a normal function, but also > > the exception table (because the new function is at a new virtual > > address) we want to search in the exception table for the old > > one and replace it with the new virtual address. > > I think this gets too specific. Telling apart code and data may make > sense, but I think beyond that thing should be expressed as > generically as possible. Imagine new special data kinds showing up > - do you envision adding a special type (and hence special handling) > for all of them? Yes and then updating the design document to include it. Would there be an more relaxed way to go about this? > > >> > #define XSPLICE_SECTION_STRING 0x00000008 /* Section is in .str */ > >> > #define XSPLICE_SECTION_ALTINSTRUCTIONS 0x00000010 /* Section has > > .altinstructions. */ > >> > >> I don't see the purpose of adding flags for a few special sections we > >> may know about now - what if over time hundreds of sections appear? > > > > We just need to know if it has - and then the hypervisor needs > > to call apply_altinstructions to redo the alternative instructions. > > > > I presume you are advocating to move this flag to an 'higher' level part > > of the structures? > > As above I'd rather see such things not special cased at all. You > already need to deal with the to be patched code having two > (or more) possible variants due to live patching at boot. I think > for the purpose of runtime patching it ought to be quite fine to > use correct, but less optimal instructions (i.e. no consideration of > alternative instructions at all). OK. > > >> > #define XSPLICE_SECTION_TEXT_INPLACE 0x00000200 /* Change is in place. > >> > */ > >> > #dekine XSPLICE_SECTION_MATCH_EXACT 0x00000400 /* Must match exactly. */ > >> > > >> > #define XSPLICE_SECTION_NO_STACKCHECK 0x00000800 /* Do not check the > >> > stack. */ > >> > >> This isn't the first reference to "stack", without me having seen a > >> description of what the word is meant to stand for in such contexts. > >> Did I overlook it? > > > > I mentioned it earlier in 'Example of trampoline and in-place splicing': > > > > 126 However it has severe drawbacks - the safety checks which have to make > > sure > > 127 the function is not on the stack - must also check every caller. For > > some > > 128 patches this could if there were an sufficient large amount of callers > > > > 129 that we would never be able to apply the update. > > > > But perhaps I should dive much deeper in about the patching > > mechanism having to check whether the function to be patched > > is on the stack. > > Yeah - the thing is that the lines you quote are precisely what I > referred to by "this isn't the first reference..." - it's not being > clarified anywhere what "stack" you talk about. In some places > it looked like you meant the stack in memory that the local > variables and spilled registers go onto, but in other places it > wasn't clear whether something else was meant. And with us > supposedly being in stop-machine state, what is on the call > stacks of each CPU should be pretty deterministic. True, the 'should' is the operative word. Hence the extra mechanism to check for stack as an fail-safe mechanism. Or if we really really are sure we can go away with - just patch it and don't do any stack checking. I will update the glossary to describe the 'stack' problem. > > >> > ### Alternative assembler > >> > > >> > Alternative assembler is a mechanism to use different instructions > >> > depending > >> > on what the CPU supports. This is done by providing multiple streams of > >> > code > >> > that can be patched in - or if the CPU does not support it - padded with > >> > `nop` operations. The alternative assembler macros cause the compiler to > >> > expand the code to place a most generic code in place - emit a special > >> > ELF .section header to tag this location. During run-time the hypervisor > >> > can leave the areas alone or patch them with an better suited opcodes. > >> > > >> > As we might be patching the alternative assembler sections as well - by > >> > providing a new better suited op-codes or perhaps with nops - we need to > >> > also re-run the alternative assembler patching after we have done our > >> > patching. > >> > >> These sections are part of .init.* and as such can't reasonably be > >> subject to patching. > > > > True, thought I thought we have some for run-time as well. > > No, we're not switching between UP and SMP like Linux does (or did). That simplifies it! Thanks. > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |