|
[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 |