All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Tamas K Lengyel <tamas@tklengyel.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	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 18:18:00 +0100	[thread overview]
Message-ID: <573A00C8.8060605@arm.com> (raw)
In-Reply-To: <CABfawhkmGqP5MhO_UUZj5Z8da9EQmx8f-4TK4maiuW2CM3ZvgA@mail.gmail.com>



On 16/05/16 17:26, Tamas K Lengyel wrote:
>
> On May 16, 2016 09:59, "Julien Grall" <julien.grall@arm.com
> <mailto:julien.grall@arm.com>> wrote:
>  >>  > 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.
>  >>  >
>  >>
>  >> If the guest is running in 32-bit mode Xen will fill the 32-bit struct,
>  >> so doing a common struct is not strictly necessary. It also requires a
>  >> bunch if union declarations to match the names between that I would
>  >> prefer to avoid. IMHO it's cleaner to do the struct definitions
>  >> separately and then do a union on top.
>  >
>  >
>  > That is not true. is_domain_32bit will check if the domain is
> configured to run 32-bit or 64-bit in EL1 (i.e the kernel level).
>  >
>  > So if you have a guest with 64-bit kernel and 32-bit userspace, Xen
> will always fill the 64-bit structure, even when the userspace is running.
>  >
>
> Hm fair point. It complicates things a bit though either way as the
> event subscriber wouldn't know which mode it received the event from
> without doing some extra checks. So I guess Xen should transmit that
> information too, at which point it could also just pick the right struct
> to fill with the current setup.

Not really, CPSR.M[4] tells you if the execution state were AArch32 or 
AArch64. vm_event_regs_* contains the cpsr fields, so the event
subscriber can determine the mode.

Actually, not all the registers in vm_event_regs_arm32 makes sense when 
the guest is a 64-bit domain. For instance, spsr_svc is for the EL1 (i.e 
kernel).

Hence the suggestion to use a structure very similar to 
vcpu_guest_core_regs.

Regards,

-- 
Julien Grall

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

  reply	other threads:[~2016-05-16 17:18 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
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 [this message]
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=573A00C8.8060605@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.