Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

On 16-09-12 01:30:22, Jan Beulich wrote: > >>> On 12.09.16 at 05:26, wrote: > > On 16-09-09 02:32:25, Jan Beulich wrote: > >> >>> On 09.09.16 at 10:09, wrote: > >> > First time, user wants to set L3 CAT of Dom1 to 0x1ff for example. The > >> >

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

>>> On 12.09.16 at 05:26, wrote: > On 16-09-09 02:32:25, Jan Beulich wrote: >> >>> On 09.09.16 at 10:09, wrote: >> > First time, user wants to set L3 CAT of Dom1 to 0x1ff for example. The >> > old_cos >> > of Dom1 is 0. L3 CAT is the first

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

On 16-09-09 11:14:50, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH 1/3] x86: refactor psr implementation in > hypervisor."): > > On 09.09.16 at 10:09, wrote: > > > Sorry, I may misunderstand you. Maybe "check_exceed_cos_max" is a good > > > name? > > > >

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

On 16-09-09 02:32:25, Jan Beulich wrote: > >>> On 09.09.16 at 10:09, wrote: > > On 16-09-08 03:54:24, Jan Beulich wrote: > >> >>> On 08.09.16 at 09:28, wrote: > >> > On 16-09-07 03:01:34, Jan Beulich wrote: > >> >> >> >>> On 25.08.16 at 07:22,

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

Jan Beulich writes ("Re: [PATCH 1/3] x86: refactor psr implementation in hypervisor."): > On 09.09.16 at 10:09, wrote: > > Sorry, I may misunderstand you. Maybe "check_exceed_cos_max" is a good name? > > According to my knowledge of English this would still need to be

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

>>> On 09.09.16 at 10:09, wrote: > On 16-09-08 03:54:24, Jan Beulich wrote: >> >>> On 08.09.16 at 09:28, wrote: >> > On 16-09-07 03:01:34, Jan Beulich wrote: >> >> >> >>> On 25.08.16 at 07:22, wrote: >> >> >> > +

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

On 16-09-08 03:54:24, Jan Beulich wrote: > >>> On 08.09.16 at 09:28, wrote: > > On 16-09-07 03:01:34, Jan Beulich wrote: > >> >> >>> On 25.08.16 at 07:22, wrote: > >> >> > +unsigned int (*exceed_range)(uint64_t *mask, struct feat_list > >>

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

>>> On 08.09.16 at 09:28, wrote: > On 16-09-07 03:01:34, Jan Beulich wrote: >> >> >>> On 25.08.16 at 07:22, wrote: >> >> > +unsigned int (*exceed_range)(uint64_t *mask, struct feat_list >> >> > *pFeat, >> >> > +

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

On 16-09-07 03:01:34, Jan Beulich wrote: > >> >>> On 25.08.16 at 07:22, wrote: > >> > + struct psr_socket_alloc_info *info); > >> > +/* > >> > + * get_old_set_new is used in set value process to get all features' > >> > + * COS

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

>> >>> On 25.08.16 at 07:22, wrote: >> > + struct psr_socket_alloc_info *info); >> > +/* >> > + * get_old_set_new is used in set value process to get all features' >> > + * COS registers values according to original cos id of the

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

Hi, Jan, Thank you very much for reviewing my patches in details! Please check my comments below. On 16-09-06 01:40:00, Jan Beulich wrote: > >>> On 25.08.16 at 07:22, wrote: > > --- a/xen/arch/x86/psr.c > > +++ b/xen/arch/x86/psr.c > > @@ -23,22 +23,116 @@ > > #define

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

>>> On 25.08.16 at 07:22, wrote: > --- a/xen/arch/x86/psr.c > +++ b/xen/arch/x86/psr.c > @@ -23,22 +23,116 @@ > #define PSR_CAT(1<<1) > #define PSR_CDP(1<<2) > > -struct psr_cat_cbm { > -union { > -uint64_t cbm; > -struct { > -

[Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

Current psr.c is designed for supporting L3 CAT/CDP. It has many limitations to add new feature. Considering to support more PSR features, we need refactor PSR implementation to make it more flexible and fulfill the principle, open for extension but closed for modification. The core of the