|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH v4 09/11] xen: arm: add cpufreq shared info definition
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |