Hi Jan
On Fri, Dec 8, 2017 at 10:07 AM, Jan Beulich wrote:
On 07.12.17 at 21:31, wrote:
>> Have questions which need to be clarified:
>>
>> If I understood correctly, new variant of set_px_pminfo is going to
>> have an extra "flag" argument, since
>> struct processor_performance doesn't hav
>>> On 07.12.17 at 21:31, wrote:
> Have questions which need to be clarified:
>
> If I understood correctly, new variant of set_px_pminfo is going to
> have an extra "flag" argument, since
> struct processor_performance doesn't have "flag" field (it contains
> "state" field instead, which has yet
Hi, Stefano, Jan
On Thu, Dec 7, 2017 at 10:45 AM, Jan Beulich wrote:
On 07.12.17 at 00:44, wrote:
>> Oleksandr would like to call set_px_pminfo from a non-hypercall context,
>> meaning that there are no XEN_GUEST_HANDLE parameters. Today, struct
>> xen_processor_performance contains a
>>
>>
>>> On 07.12.17 at 00:44, wrote:
> Oleksandr would like to call set_px_pminfo from a non-hypercall context,
> meaning that there are no XEN_GUEST_HANDLE parameters. Today, struct
> xen_processor_performance contains a
>
> XEN_GUEST_HANDLE(xen_processor_px_t) states;
>
> field. Instead of "faki
On Wed, 6 Dec 2017, Jan Beulich wrote:
> >>> On 05.12.17 at 21:48, wrote:
> > You are right. We need to define a new struct for internal usage, for
> > example:
> >
> > struct xen_processor_performance_internal {
> > uint32_t flags; /* flag for Px sub info type */
> > uint32_t platfor
>>> On 05.12.17 at 21:48, wrote:
> You are right. We need to define a new struct for internal usage, for
> example:
>
> struct xen_processor_performance_internal {
> uint32_t flags; /* flag for Px sub info type */
> uint32_t platform_limit; /* Platform limitation on freq usage */
>
On Tue, 5 Dec 2017, Oleksandr Tyshchenko wrote:
> Hi Stefano
>
> On Tue, Dec 5, 2017 at 12:46 AM, Stefano Stabellini
> wrote:
> > On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote:
> >> Hi, Stefano
> >>
> >> On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
> >> wrote:
> >> > On Thu, 9 Nov 2017, O
Hi Stefano
On Tue, Dec 5, 2017 at 12:46 AM, Stefano Stabellini
wrote:
> On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote:
>> Hi, Stefano
>>
>> On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
>> wrote:
>> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> >> From: Oleksandr Dmytryshyn
>> >>
>
On Mon, 4 Dec 2017, Oleksandr Tyshchenko wrote:
> Hi, Stefano
>
> On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
> wrote:
> > On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> >> From: Oleksandr Dmytryshyn
> >>
> >> First implementation of the cpufreq driver has been
> >> written with x86 in
Hi, Stefano
On Sat, Dec 2, 2017 at 3:37 AM, Stefano Stabellini
wrote:
> On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Dmytryshyn
>>
>> First implementation of the cpufreq driver has been
>> written with x86 in mind. This patch makes possible
>> the cpufreq driver be working
On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn
>
> First implementation of the cpufreq driver has been
> written with x86 in mind. This patch makes possible
> the cpufreq driver be working on both x86 and arm
> architectures.
>
> This is a rebased version of the ori
11 matches
Mail list logo
