On Apr 20, 2016 6:05 PM, "Jan Beulich" <jbeul...@suse.com> wrote:
>
> >>> Konrad Rzeszutek Wilk <konrad.w...@oracle.com> 04/20/16 6:00 PM >>>
> >> >+ size_t pages; /* Total pages for [text,rw,ro]_addr */
> >>
> >> Why size_t and not just unsigned int?
> >
> >Oh. I was somehow under the impression you liked size_t more than
> >unsignged int! I will change it over.
>
> When used where actually talking about sizes, I indeed prefer size_t. But
> here we have a count which we know will be much lower than UINT_MAX.
>
> >> >+static void calc_section(struct xsplice_elf_sec *sec, size_t *size)
> >> >+{
> >> >+ Elf_Shdr *s = sec->sec;
> >> >+ size_t align_size;
> >> >+
> >> >+ align_size = ROUNDUP(*size, s->sh_addralign);
> >> >+ s->sh_entsize = align_size;
> >>
> >> So this is one of the places (the only one?) where the section header
gets
> >> altered. Are you not expecting problems down the road resulting from
> >> overwriting this field? After all it's used not just in control
sections...
> >
> >The 'man elf' tells me :
> >"Some sections hold a table of fixed-sized entries, such as a symbol
> >table. For such a section, this member gives the size in bytes for each
entry.
> >This member contains zero if the section does not hold a table of
> >fixed-size entries."
>
> My main concern is that SHF_MERGE sections (i.e. ordinary data ones) also
> already use this field.
OK. Let me add the 'offset' member (in xsplice_elf_sec) to store the value.
Albeit it only gets used during move_payload. And later that offset value
can easily computed using ->load_addr minus ->data.
Perhaps I should introduce an temporary array to hold this value instead?
>
> >> >+ /* Don't copy NOBITS - such as BSS. */
> >> >+ if ( elf->sec[i].sec->sh_type != SHT_NOBITS )
> >> >+ {
> >> >+ memcpy(elf->sec[i].load_addr, elf->sec[i].data,
> >> >+ elf->sec[i].sec->sh_size);
> >> >+ dprintk(XENLOG_DEBUG, XSPLICE "%s: Loaded %s at
0x%p\n",
> >> >+ elf->name, elf->sec[i].name,
elf->sec[i].load_addr);
> >> >+ }
> >>
> >> "else memset();" is what I would have expected here. Now I see that the
> >> allocation function clears the pages (in a bogusly open coded way,
instead
> >> of using vzalloc()), but why is that so?
> >
> >B/c we end up having vzalloc_xen (oh wait, we made that go away). Yes
> >we do need an memset or introduce vzalloc_xen (and keep vmalloc_xen?).
> >
> >Your call - memset or introduce vzalloc_xen ?
>
> The latter would be my preference.
OK, will do.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
