Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

2016-08-18 Thread Andrew Cooper
On 18/08/16 02:59, Doug Goldstein wrote: > On 8/17/16 7:49 AM, Jan Beulich wrote: > On 17.08.16 at 01:28, wrote: >>> There can only ever be one mtrr_if now and that is the generic >>> implementation >> This is only true when taking into consideration that cpu_has_mtrr >> is #define-d to 1 righ

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

2016-08-18 Thread Jan Beulich
>>> On 18.08.16 at 03:59, wrote: > On 8/17/16 7:49 AM, Jan Beulich wrote: > On 17.08.16 at 01:28, wrote: >>> There can only ever be one mtrr_if now and that is the generic >>> implementation >> >> This is only true when taking into consideration that cpu_has_mtrr >> is #define-d to 1 right n

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

2016-08-17 Thread Doug Goldstein
On 8/17/16 7:49 AM, Jan Beulich wrote: On 17.08.16 at 01:28, wrote: >> There can only ever be one mtrr_if now and that is the generic >> implementation > > This is only true when taking into consideration that cpu_has_mtrr > is #define-d to 1 right now. I'm not sure that's actually a good >

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

2016-08-17 Thread Jan Beulich
>>> On 17.08.16 at 01:28, wrote: > There can only ever be one mtrr_if now and that is the generic > implementation This is only true when taking into consideration that cpu_has_mtrr is #define-d to 1 right now. I'm not sure that's actually a good assumption (especially when think about running Xe

[Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

2016-08-16 Thread Doug Goldstein
There can only ever be one mtrr_if now and that is the generic implementation so instead of going through an indirect call change everything to call the generic implementation directly. The is_cpu() macro would result in the left side always being equal to X86_VENDOR_INTEL for the generic implement