On 16/05/16 17:26, Tamas K Lengyel wrote:
On May 16, 2016 09:59, "Julien Grall" <julien.gr...@arm.com
<mailto:julien.gr...@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
