xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Tamas K Lengyel <tamas@tklengyel.com>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Razvan Cojocaru <rcojocaru@bitdefender.com>
Subject: Re: [PATCH v3 4/9] arm/vm_event: get/set registers
Date: Mon, 16 May 2016 11:14:42 +0100	[thread overview]
Message-ID: <57399D92.1030905@arm.com> (raw)
In-Reply-To: <1462373480-20206-4-git-send-email-tamas@tklengyel.com>

Hi Tamas,

On 04/05/16 15:51, Tamas K Lengyel wrote:
> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
> index a3fc4ce..814d0da 100644
> --- a/xen/include/asm-arm/vm_event.h
> +++ b/xen/include/asm-arm/vm_event.h
> @@ -48,15 +48,10 @@ void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp)
>       /* Not supported on ARM. */
>   }
>
> -static inline
> -void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
> -{
> -    /* Not supported on ARM. */
> -}
> +void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
>
> -static inline void vm_event_fill_regs(vm_event_request_t *req)
> -{
> -    /* Not supported on ARM. */
> -}
> +void vm_event_fill_regs(vm_event_request_t *req,
> +                        const struct cpu_user_regs *regs,
> +                        struct domain *d);
>
>   #endif /* __ASM_ARM_VM_EVENT_H__ */
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index 3acf217..fabeee8 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -129,8 +129,8 @@
>   #define VM_EVENT_X86_XCR0   3
>
>   /*
> - * Using a custom struct (not hvm_hw_cpu) so as to not fill
> - * the vm_event ring buffer too quickly.
> + * Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM

You may want to rework this sentence as hvm_hw_cpu does not exist on 
ARM/ARM64.

> + * so as to not fill the vm_event ring buffer too quickly.
>    */
>   struct vm_event_regs_x86 {
>       uint64_t rax;
> @@ -168,6 +168,54 @@ struct vm_event_regs_x86 {
>       uint32_t _pad;
>   };
>
> +struct vm_event_regs_arm32 {
> +    uint32_t r0_usr;
> +    uint32_t r1_usr;
> +    uint32_t r2_usr;
> +    uint32_t r3_usr;
> +    uint32_t r4_usr;
> +    uint32_t r5_usr;
> +    uint32_t r6_usr;
> +    uint32_t r7_usr;
> +    uint32_t r8_usr;
> +    uint32_t r9_usr;
> +    uint32_t r10_usr;
> +    uint32_t r12_usr;
> +    uint32_t lr_usr;
> +    uint32_t sp_usr;
> +    uint32_t sp_svc;
> +    uint32_t spsr_svc;
> +    uint32_t fp;
> +    uint32_t pc;
> +    uint32_t cpsr;
> +    uint32_t ttbr0;
> +    uint32_t ttbr1;
> +};
> +
> +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 x16;
> +    uint64_t lr;
> +    uint64_t sp_el0;
> +    uint64_t sp_el1;
> +    uint32_t spsr_el1;
> +    uint64_t fp;
> +    uint64_t pc;
> +    uint32_t cpsr;
> +    uint64_t ttbr0;
> +    uint64_t ttbr1;
> +};

By defining 2 distinct structures, it will be more difficult for the 
introspection tools to inspect registers of an Aarch64 domain running in 
AArch32 mode. They wouldn't be able to re-use code for AArch32 domain 
because the structure fields are different.

The ARM ARM (see D1.20.1 in ARM DDI 0487A.i) provides a mapping between 
AArch32 state and AArch64 state. If you use it to define the layout of a 
common structure, the support of AArch32 state for AArch64 domain will 
come free.

> +
>   /*
>    * mem_access flag definitions
>    *
> @@ -256,6 +304,8 @@ typedef struct vm_event_st {
>       union {
>           union {
>               struct vm_event_regs_x86 x86;
> +            struct vm_event_regs_arm32 arm32;
> +            struct vm_event_regs_arm64 arm64;
>           } regs;
>
>           struct vm_event_emul_read_data emul_read_data;
>

Regards,

-- 
Julien Grall

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

  reply	other threads:[~2016-05-16 10:14 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-04 14:51 [PATCH v3 1/9] monitor: Rename vm_event_monitor_get_capabilities Tamas K Lengyel
2016-05-04 14:51 ` [PATCH v3 2/9] monitor: Don't call vm_event_fill_regs from common Tamas K Lengyel
2016-05-05  9:34   ` Razvan Cojocaru
2016-05-16  9:48   ` Julien Grall
2016-05-27 18:58     ` Tamas K Lengyel
2016-05-04 14:51 ` [PATCH v3 3/9] monitor: ARM SMC events Tamas K Lengyel
2016-05-05  9:36   ` Razvan Cojocaru
2016-05-16  9:56   ` Julien Grall
2016-05-04 14:51 ` [PATCH v3 4/9] arm/vm_event: get/set registers Tamas K Lengyel
2016-05-16 10:14   ` Julien Grall [this message]
2016-05-16 15:37     ` Tamas K Lengyel
2016-05-16 15:58       ` Julien Grall
2016-05-16 16:26         ` Tamas K Lengyel
2016-05-16 17:18           ` Julien Grall
2016-05-04 14:51 ` [PATCH v3 5/9] tools/libxc: add xc_monitor_privileged_call Tamas K Lengyel
2016-05-04 20:08   ` Konrad Rzeszutek Wilk
2016-05-04 22:12     ` Tamas K Lengyel
2016-05-04 14:51 ` [PATCH v3 6/9] tools/xen-access: add test-case for ARM SMC Tamas K Lengyel
2016-05-04 15:35   ` Jan Beulich
2016-05-04 17:16     ` Tamas K Lengyel
2016-05-04 17:33       ` Wei Liu
2016-05-04 17:42         ` Tamas K Lengyel
2016-05-05 16:25       ` Jan Beulich
     [not found]         ` <CABfawh=gWOs3AtsTdYaDj61ph2jumjX6Q=0uFVeahPH99DY9qg@mail.gmail.com>
     [not found]           ` <CABfawhknB62vZJFvcJv6VAGzw0toZUCXBHyEnzm99+N1ZLBYEg@mail.gmail.com>
2016-05-05 18:25             ` Tamas K Lengyel
2016-05-05  9:37   ` Razvan Cojocaru
2016-05-04 14:51 ` [PATCH v3 7/9] x86/hvm: Rename hvm/event to hvm/monitor Tamas K Lengyel
2016-05-05  9:39   ` Razvan Cojocaru
2016-05-04 14:51 ` [PATCH v3 8/9] x86/hvm: Add debug exception vm_events Tamas K Lengyel
2016-05-05  9:56   ` Razvan Cojocaru
2016-05-04 14:51 ` [PATCH v3 9/9] MAINTAINERS: Update monitor/vm_event covered code Tamas K Lengyel
2016-05-05  9:53   ` Razvan Cojocaru

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57399D92.1030905@arm.com \
    --to=julien.grall@arm.com \
    --cc=rcojocaru@bitdefender.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas@tklengyel.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).