>>> On 15.03.17 at 09:18, wrote:
> On 17-03-15 01:40:06, Jan Beulich wrote:
>> >>> On 15.03.17 at 03:52, wrote:
>> > Sorry, I may not fully understand your meaning. My thoughts are below.
>> > 1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';
>> >
>> > 2. After that, we get valid
On 17-03-15 01:40:06, Jan Beulich wrote:
> >>> On 15.03.17 at 03:52, wrote:
> > Sorry, I may not fully understand your meaning. My thoughts are below.
> > 1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';
> >
> > 2. After that, we get valid cpumask through cpupool_domain_cpumask();
>>> On 15.03.17 at 03:52, wrote:
> Sorry, I may not fully understand your meaning. My thoughts are below.
> 1. We set 'd->arch.psr_cos_ids[socket] = cos;' in 'psr_set_val';
>
> 2. After that, we get valid cpumask through cpupool_domain_cpumask();
>
> 3. If the actual valid cpumask changed after
On 17-03-14 04:24:51, Jan Beulich wrote:
> >>> On 14.03.17 at 10:21, wrote:
> > On 17-03-14 00:29:09, Jan Beulich wrote:
> >> >>> Yi Sun 03/14/17 3:42 AM >>>
> >> >There are three scenarios. E.g.
> >> >1. User calls domctl interface on Dom0 to set a COS ID 1 for Dom1 into its
> >> >psr_cos_ids[].
>>> On 14.03.17 at 10:21, wrote:
> On 17-03-14 00:29:09, Jan Beulich wrote:
>> >>> Yi Sun 03/14/17 3:42 AM >>>
>> >There are three scenarios. E.g.
>> >1. User calls domctl interface on Dom0 to set a COS ID 1 for Dom1 into its
>> >psr_cos_ids[]. Then, Dom1 is scheduled so that 'psr_ctxt_switch_to(
On 17-03-14 00:29:09, Jan Beulich wrote:
> >>> Yi Sun 03/14/17 3:42 AM >>>
> >There are three scenarios. E.g.
> >1. User calls domctl interface on Dom0 to set a COS ID 1 for Dom1 into its
> >psr_cos_ids[]. Then, Dom1 is scheduled so that 'psr_ctxt_switch_to()' is
> >called which makes COS ID 1 wor
>>> Yi Sun 03/14/17 3:42 AM >>>
>There are three scenarios. E.g.
>1. User calls domctl interface on Dom0 to set a COS ID 1 for Dom1 into its
>psr_cos_ids[]. Then, Dom1 is scheduled so that 'psr_ctxt_switch_to()' is
>called which makes COS ID 1 work. For this case, we do not any action.
>
>2. Dom1
On 17-03-13 06:35:33, Jan Beulich wrote:
> >>> On 13.03.17 at 03:36, wrote:
> > On 17-03-10 02:09:55, Jan Beulich wrote:
> >> >>> On 10.03.17 at 03:54, wrote:
> >> > On 17-03-08 09:07:10, Jan Beulich wrote:
> >> >> >>> On 15.02.17 at 09:49, wrote:
> >> >> > +ref[old_cos]--;
> >> >> > +sp
>>> On 13.03.17 at 03:36, wrote:
> On 17-03-10 02:09:55, Jan Beulich wrote:
>> >>> On 10.03.17 at 03:54, wrote:
>> > On 17-03-08 09:07:10, Jan Beulich wrote:
>> >> >>> On 15.02.17 at 09:49, wrote:
>> >> > +ref[old_cos]--;
>> >> > +spin_unlock(&info->ref_lock);
>> >> > +
>> >> > +/*
>
On 17-03-10 02:09:55, Jan Beulich wrote:
> >>> On 10.03.17 at 03:54, wrote:
> > On 17-03-08 09:07:10, Jan Beulich wrote:
> >> >>> On 15.02.17 at 09:49, wrote:
> >> > +static int write_psr_msr(unsigned int socket, unsigned int cos,
> >> > + const uint64_t *val)
> >> > +{
>
>>> On 10.03.17 at 08:46, wrote:
> On 17-03-08 09:07:10, Jan Beulich wrote:
> [...]
>> > /* Called with domain lock held, no extra lock needed for 'psr_cos_ids' */
>> > static void psr_free_cos(struct domain *d)
>> > {
>> > -if( !d->arch.psr_cos_ids )
>> > +unsigned int socket, cos;
>>
>>> On 10.03.17 at 03:54, wrote:
> On 17-03-08 09:07:10, Jan Beulich wrote:
>> >>> On 15.02.17 at 09:49, wrote:
>> > +static int write_psr_msr(unsigned int socket, unsigned int cos,
>> > + const uint64_t *val)
>> > +{
>> > +return -ENOENT;
>> > +}
>>
>> Is this functi
On 17-03-08 09:07:10, Jan Beulich wrote:
[...]
> > /* Called with domain lock held, no extra lock needed for 'psr_cos_ids' */
> > static void psr_free_cos(struct domain *d)
> > {
> > -if( !d->arch.psr_cos_ids )
> > +unsigned int socket, cos;
> > +
> > +if ( !d->arch.psr_cos_ids )
> >
On 17-03-08 09:07:10, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49, wrote:
> > As set value flow is the most complicated one in psr, it will be
> > divided to some patches to make things clearer. This patch
> > implements the set value framework to show a whole picture firstly.
> >
> > It also c
>>> On 15.02.17 at 09:49, wrote:
> As set value flow is the most complicated one in psr, it will be
> divided to some patches to make things clearer. This patch
> implements the set value framework to show a whole picture firstly.
>
> It also changes domctl interface to make it more general.
>
>
On 17-02-28 13:58:55, Roger Pau Monn� wrote:
> > +static int find_cos(const uint64_t *val, uint32_t array_len,
> > +enum psr_feat_type feat_type,
> > +const struct psr_socket_info *info)
> > +{
> ASSERT(spin_is_locked(info->ref_lock));
> > +return -EN
On Wed, Feb 15, 2017 at 04:49:23PM +0800, Yi Sun wrote:
> As set value flow is the most complicated one in psr, it will be
> divided to some patches to make things clearer. This patch
> implements the set value framework to show a whole picture firstly.
>
> It also changes domctl interface to make
>>> Yi Sun 02/27/17 8:06 AM >>>
>On 17-02-26 17:41:43, Wei Liu wrote:
>> On Wed, Feb 15, 2017 at 04:49:23PM +0800, Yi Sun wrote:
>> > +/*
>> > + * Step 0:
>> > + * old_cos means the COS ID current domain is using. By default, it
>> > is 0.
>> > + *
>> > + * For every COS ID, t
On 17-02-26 17:41:43, Wei Liu wrote:
> On Wed, Feb 15, 2017 at 04:49:23PM +0800, Yi Sun wrote:
> [...]
> > +int psr_set_val(struct domain *d, unsigned int socket,
> > +uint64_t val, enum cbm_type type)
>
> IMHO it would be far better to use goto style error handling in such a
> com
On Wed, Feb 15, 2017 at 04:49:23PM +0800, Yi Sun wrote:
[...]
> +int psr_set_val(struct domain *d, unsigned int socket,
> +uint64_t val, enum cbm_type type)
IMHO it would be far better to use goto style error handling in such a
complex function. You can avoid missing one of the exi
As set value flow is the most complicated one in psr, it will be
divided to some patches to make things clearer. This patch
implements the set value framework to show a whole picture firstly.
It also changes domctl interface to make it more general.
To make the set value flow be general and can s
21 matches
Mail list logo
