Re: [Xen-devel] [PATCH v8 4/6] arm/vm_event: get/set registers

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel