[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 4/6] arm/vm_event: get/set registers
On 07/06/16 10:43, Jan Beulich wrote: >>>> On 05.07.16 at 20:37, <tamas.lengyel@xxxxxxxxxxxx> wrote: >> +struct vm_event_regs_arm64 { >> + uint64_t x0; >> + uint64_t x1; >> + uint64_t x2; >> + uint64_t x3; >> + uint64_t x4; >> + uint64_t x5; >> + uint64_t x6; >> + uint64_t x7; >> + uint64_t x8; >> + uint64_t x9; >> + uint64_t x10; >> + uint64_t x11; >> + uint64_t x12; >> + uint64_t x13; >> + uint64_t x14; >> + uint64_t x15; >> + uint64_t x16; >> + uint64_t x17; >> + uint64_t x18; >> + uint64_t x19; >> + uint64_t x20; >> + uint64_t x21; >> + uint64_t x22; >> + uint64_t x23; >> + uint64_t x24; >> + uint64_t x25; >> + uint64_t x26; >> + uint64_t x27; >> + uint64_t x28; >> + uint64_t x29; >> + uint64_t x30; >> + uint64_t pc; >> +}; > > Isn't the stack pointer a fully separate register in aarch64? Not > making available something as essential as that seems wrong to > me. > >> @@ -246,10 +311,14 @@ struct vm_event_sharing { >> uint32_t _pad; >> }; >> >> +#define VM_EVENT_MAX_DATA_SIZE \ >> + (sizeof(struct vm_event_regs_x86) > sizeof(struct vm_event_regs_arm) ? \ >> + sizeof(struct vm_event_regs_x86) : sizeof(struct vm_event_regs_arm)) >> + >> struct vm_event_emul_read_data { >> uint32_t size; >> /* The struct is used in a union with vm_event_regs_x86. */ >> - uint8_t data[sizeof(struct vm_event_regs_x86) - sizeof(uint32_t)]; >> + uint8_t data[VM_EVENT_MAX_DATA_SIZE - sizeof(uint32_t)]; >> }; > > Would there be a problem leaving this alone, i.e. not growing the > current limit? I ask because the way VM_EVENT_MAX_DATA_SIZE gets > established doesn't look very scalable - just think about how that > would look like after half a dozen more architectures got added. > >> @@ -275,6 +344,7 @@ typedef struct vm_event_st { >> union { >> union { >> struct vm_event_regs_x86 x86; >> + struct vm_event_regs_arm arm; >> } regs; > > So the growth in size here then is not really a problem? Should be fine for our purposes. Thanks, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |