On Thu, Oct 15, Wei Liu wrote:
> No, because 1) staging is not using GCC5, 2) staging has debug=y.
Are there enough resources to address #2?
Build once with debug=y and once without?
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists
>>> On 16.10.15 at 10:24, wrote:
> On Thu, Oct 15, 2015 at 09:47:37AM -0600, Jan Beulich wrote:
>>
>> Ah, yes, in cases like this it should always be followed by return
>> (or whatever else is suitable). Sorry for not having spotted this
>> during review.
>>
> Sorry for this bug. Is it proper to
On Thu, Oct 15, 2015 at 09:47:37AM -0600, Jan Beulich wrote:
>
> Ah, yes, in cases like this it should always be followed by return
> (or whatever else is suitable). Sorry for not having spotted this
> during review.
>
Sorry for this bug. Is it proper to fix this bug by just adding a
return after
>>> On 15.10.15 at 17:10, wrote:
> On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote:
>> On Tue, Oct 13, He Chen wrote:
>>
>> > +int psr_set_l3_cbm(struct domain *d, unsigned int socket,
>> > + uint64_t cbm, enum cbm_type type)
>> > {
>>
>> > +uint64_t cbm_data,
On Thu, Oct 15, 2015 at 04:26:47PM +0100, Wei Liu wrote:
> On Thu, Oct 15, 2015 at 05:22:39PM +0200, Olaf Hering wrote:
> > On Thu, Oct 15, Wei Liu wrote:
> >
> > > On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote:
> > > > gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging
On Thu, Oct 15, 2015 at 05:22:39PM +0200, Olaf Hering wrote:
> On Thu, Oct 15, Wei Liu wrote:
>
> > On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote:
> > > gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging fails:
> > Is it because in non-debug build ASSERT_UNREACHABLE is n
On Thu, Oct 15, Wei Liu wrote:
> On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote:
> > gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging fails:
> Is it because in non-debug build ASSERT_UNREACHABLE is nop?
That might explain it.
Does the staging build test catch this bug
On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote:
> On Tue, Oct 13, He Chen wrote:
>
> > +int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> > + uint64_t cbm, enum cbm_type type)
> > {
>
> > +uint64_t cbm_data, cbm_code;
>
> > +switch ( type )
> >
On Tue, Oct 13, He Chen wrote:
> +int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> + uint64_t cbm, enum cbm_type type)
> {
> +uint64_t cbm_data, cbm_code;
> +switch ( type )
> {
> +case PSR_CBM_TYPE_L3:
> +cbm_code = cbm;
> +break;
On Tue, Oct 13, 2015 at 09:38:58AM -0600, Jan Beulich wrote:
> >>> On 13.10.15 at 10:53, wrote:
> > @@ -331,19 +357,34 @@ static bool_t psr_check_cbm(unsigned int cbm_len,
> > uint64_t cbm)
> > struct cos_cbm_info
> > {
> > unsigned int cos;
> > -uint64_t cbm;
> > +uint64_t cbm_cod
>>> On 13.10.15 at 10:53, wrote:
> @@ -331,19 +357,34 @@ static bool_t psr_check_cbm(unsigned int cbm_len,
> uint64_t cbm)
> struct cos_cbm_info
> {
> unsigned int cos;
> -uint64_t cbm;
> +uint64_t cbm_code;
> +uint64_t cbm_data;
> +bool_t cdp;
> };
The bool_t field reall
CDP extends CAT and provides the capacity to control L3 code & data
cache. With CDP, one COS corresponds to two CMBs(code & data). cbm_type
is added to distinguish different CBM operations. Besides, new domctl
cmds are introdunced to support set/get CDP CBM. Some CAT functions to
operation CBMs are
12 matches
Mail list logo
