|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Is: ARM maintainers advice ..Was:Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
On Sat, Apr 09, 2016 at 10:36:02PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
> > >>> On 07.04.16 at 05:09, <konrad.wilk@xxxxxxxxxx> wrote:
> > >> > + uint8_t *old_ptr;
> > >> > +
> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> > >> > +
> > >> > + old_ptr = (uint8_t *)func->old_addr;
> > >>
> > >> (Considering this cast, the "old_addr" member should be
> > >> unsigned long (or void *), not uint64_t: The latest on ARM32
> > >> such would otherwise cause problems.)
> > >
> > > I has to be uint8_t to make the single byte modifications. Keep
> > > also in mind that this file is only for x86.
> >
> > old_addr can't reasonably be uint8_t, so I can only assume you're
> > mixing up things here. (And yes, I do realize this is x86 code, but
> > my reference to ARM32 was only mean to say that there you'll
> > need to do something similar, and casting uint64_t to whatever
> > kind of pointer type is not going to work without compiler warning.)
>
> Way back .. when we spoke about the .xsplice.funcs structure
> you recommended to make the types be either uintXX specific
> or Elf types. I choose Elf types but then we realized that
> ARM32 hypervisor would be involved which of course would have
> a different size of the structure. So I went with uintXXX
> to save a bit of headache (specifically those BUILD_BUG_ON
> checks).
>
> I can't see making the old_addr be unsigned long or void *,
> which means going back to Elf types. And for ARM32 I will
> have to deal with a different structure size.
CC-ing Stefano and Julien here to advise. I ended up
exposing the ABI part in sysctl.h (and design document as):
#define XSPLICE_PAYLOAD_VERSION 1
/*
* .xsplice.funcs structure layout defined in the `Payload format`
* section in the xSplice design document.
*
* The size should be exactly 64 bytes.
*/
struct xsplice_patch_func {
const char *name; /* Name of function to be patched. */
uint64_t new_addr;
uint64_t old_addr; /* Can be zero and name will be looked up. */
uint32_t new_size;
uint32_t old_size;
uint8_t version; /* MUST be XSPLICE_PAYLOAD_VERSION. */
uint8_t pad[31]; /* MUST be zero filled. */
};
typedef struct xsplice_patch_func xsplice_patch_func_t;
Which looks nice.
When the ELF file is loaded we load it as this structure:
[x86]
#ifndef CONFIG_ARM
struct xsplice_patch_func_internal {
const char *name;
void *new_addr;
void *old_addr;
uint32_t new_size;
uint32_t old_size;
uint8_t version;
union {
uint8_t undo[8];
uint8_t pad[31];
} u;
};
#else
[ARM]
struct xsplice_patch_func_internal {
const char *name;
uint32_t _pad0;
void *new_addr;
uint32_t _pad1;
void *old_addr;
uint32_t _pad2;
uint32_t new_size;
uint32_t old_size;
uint8_t version;
union {
uint8_t pad[31];
} u;
};
#endif
That allows the size and offsets to be the same. I checked under ARM32
builds:
struct xsplice_patch_func_internal {
const char * name; /* 0 4 */
uint32_t _pad0; /* 4 4 */
void * new_addr; /* 8 4 */
uint32_t _pad1; /* 12 4 */
void * old_addr; /* 16 4 */
uint32_t _pad2; /* 20 4 */
uint32_t new_size; /* 24 4 */
uint32_t old_size; /* 28 4 */
uint8_t version; /* 32 1 */
union {
uint8_t pad[31]; /* 31 */
} u; /* 33 31 */
/* --- cacheline 1 boundary (64 bytes) --- */
/* size: 64, cachelines: 1, members: 10 */
};
So it all looks correct. (and I can cast the old_addr to uint8_t).
Naturally we can expand the pad[] to hold whatever is needed
when implementing xSplice under ARM
However I would appreciate advise from ARM folks if I made some
wrong assumptions..
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |