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
next prev parent 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.