Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared info definition

[Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>]

On Thu, Nov 6, 2014 at 5:27 PM, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Thu, 6 Nov 2014, Oleksandr Dmytryshyn wrote:
>> On Tue, Nov 4, 2014 at 6:12 PM, Stefano Stabellini
>> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > On Tue, 4 Nov 2014, Oleksandr Dmytryshyn wrote:
>> >> This shared info will be used by hwdom-cpufreq driver
>> >> to send commands to the cpufreq driver in the hwdom.
>> >>
>> >> Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx>
>> >> ---
>> >>  xen/include/asm-arm/shared.h  | 14 ++++++++++++++
>> >>  xen/include/public/arch-arm.h |  8 ++++++++
>> >>  2 files changed, 22 insertions(+)
>> >>  create mode 100644 xen/include/asm-arm/shared.h
>> >>
>> >> diff --git a/xen/include/asm-arm/shared.h b/xen/include/asm-arm/shared.h
>> >> new file mode 100644
>> >> index 0000000..4906f38
>> >> --- /dev/null
>> >> +++ b/xen/include/asm-arm/shared.h
>> >> @@ -0,0 +1,14 @@
>> >> +#ifndef __XEN_ARM_SHARED_H__
>> >> +#define __XEN_ARM_SHARED_H__
>> >> +
>> >> +#define GET_SET_SHARED(type, field)                                 \
>> >> +static inline type *arch_get_##field##_addr(const struct domain *d) \
>> >> +{                                                                   \
>> >> +   return &d->shared_info->arch.field;                              \
>> >> +}
>> >> +
>> >> +GET_SET_SHARED(struct cpufreq_sh_info, cpufreq)
>> >> +
>> >> +#undef GET_SET_SHARED
>> >> +
>> >> +#endif /* __XEN_ARM_SHARED_H__ */
>> >> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>> >> index 7496556..7eef6f7 100644
>> >> --- a/xen/include/public/arch-arm.h
>> >> +++ b/xen/include/public/arch-arm.h
>> >> @@ -309,7 +309,15 @@ struct arch_vcpu_info {
>> >>  };
>> >>  typedef struct arch_vcpu_info arch_vcpu_info_t;
>> >>
>> >> +struct cpufreq_sh_info {
>> >> +    uint32_t cpu;       /* Physical CPU number */
>> >> +    uint32_t freq;      /* Frequency in KHz */
>> >> +    uint32_t relation;  /* CPUFREQ_RELATION_L/H (0) or (1) */
>> >> +    int32_t result;        /* Returned result of the operation */
>> >> +};
>> >> +
>> >>  struct arch_shared_info {
>> >> +    struct cpufreq_sh_info cpufreq;
>> >>  };
>> >>  typedef struct arch_shared_info arch_shared_info_t;
>> >>  typedef uint64_t xen_callback_t;
>> >
>> > This introduces one global struct cpufreq_sh_info. Do we need to worry
>> > about locking? Is it possible that we might want to send two commands
>> > simultaneously? How does Xen get to know that Dom0 completed the
>> > previous operation before starting a new one?
>> As I've written before:
>> I'll create an event channel between Xen and hwdom.
>> In this case Xen will be able to know that hwdom completed the
>> previous operation before starting a new one.
>
> I don't think that Xen can receive event channel notifications.  You
> might have to introduce some kind of synchronization protocol within
> struct cpufreq_sh_info.
>
> It would greatly simplify your problem if you made sure that the guest
> cpufreq "handler" only ran on one particular vcpu. Maybe you could
> register the vcpu handler at boot time via hypercall. Otherwise you
> could have one struct cpufreq_sh_info per guest vcpu.
I'll think about it.
I've checked that Xen can receive event channel notifications (and hwdom too).
(I've created an event channel between Xen and hwdom).

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