>>> On 08.05.19 at 17:40, <julien.gr...@arm.com> wrote:
> On 23/04/2019 09:10, Andrii Anisov wrote:
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -163,15 +163,23 @@ struct vcpu
>> void *sched_priv; /* scheduler-specific data */
>>
>> struct vcpu_runstate_info runstate;
>> +
>> + spinlock_t mapped_runstate_lock;
>> +
>> #ifndef CONFIG_COMPAT
>> # define runstate_guest(v) ((v)->runstate_guest)
>> XEN_GUEST_HANDLE(vcpu_runstate_info_t) runstate_guest; /* guest
>> address */
>> + vcpu_runstate_info_t *mapped_runstate;
>> #else
>> # define runstate_guest(v) ((v)->runstate_guest.native)
>> union {
>> XEN_GUEST_HANDLE(vcpu_runstate_info_t) native;
>> XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat;
>> } runstate_guest; /* guest address */
>> + union {
>> + vcpu_runstate_info_t* native;
>> + vcpu_runstate_info_compat_t* compat;
>> + } mapped_runstate; /* guest address */
>
> The combination of mapped_runstate and runstate_guest is a bit confusing. I
> think you want to rework the interface to show that only one is possible at
> the
> time and make clear which one is used by who. Maybe:
>
> union
> {
> /* Legacy interface to be used when the guest provides a virtual address
> */
> union {
> XEN_GUEST_HANDLE(vcpu_runstate_info_t) native;
> ...
> } virt;
>
> /* Interface used when the guest provides a physical address */
> union {
> } phys;
> } runstate_guest.
>
> runstate_guest_type /* could be a bool or enum */
>
> Jan what do you think?
I fully agree - no mixing of approaches here, if possible. However,
care needs to be taken that after a domain reset the new kernel
can chose the opposite model. Question is whether there are even
other cases where independent components (say boot loader and
OS) may need to be permitted to chose models independently of
one another.
As a side note, Andrii - would you please avoid sending double mail
to xen-devel (addresses differing just by domain used)?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
