Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-07 Thread Toshi Kani
On Fri, 2015-08-07 at 16:26 -0700, Luis R. Rodriguez wrote: > On Fri, Aug 7, 2015 at 4:08 PM, Toshi Kani wrote: > > On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote: > > > On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote: > > > > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrot

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-07 Thread Luis R. Rodriguez
On Fri, Aug 7, 2015 at 4:08 PM, Toshi Kani wrote: > On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote: >> On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote: >> > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote: >> > > On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote: >> > > >

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-07 Thread Toshi Kani
On Fri, 2015-08-07 at 17:08 -0600, Toshi Kani wrote: > On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote: > > On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote: > > > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote: > > > > On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani > > > > wr

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-07 Thread Toshi Kani
On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote: > On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote: > > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote: > > > On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote: > > > > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrot

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-07 Thread Luis R. Rodriguez
On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote: > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote: >> On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote: >> > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote: >> > > On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote: >> > > >

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-07 Thread Toshi Kani
On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote: > On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote: > > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote: > > > On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote: > > > > On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote: >

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-07 Thread Luis R. Rodriguez
On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote: > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote: >> On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote: >> > On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote: >> > > > > > On 12.06.15 at 01:23, wrote: >> > > > There are two usages

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-06 Thread Toshi Kani
On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote: > On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote: > > On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote: > > > > > > On 12.06.15 at 01:23, wrote: > > > > There are two usages on MTRRs: > > > > 1) MTRR entries set by firmware > > >

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-06 Thread Luis R. Rodriguez
On Thu, Aug 6, 2015 at 12:53 PM, Luis R. Rodriguez wrote: > For those type of OSes... > could it be possible to negotiate or hint to the platform through an > attribute somehow that the OS has such capability to not use MTRR? And if that's not possible how about a new platform setting that would

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-08-06 Thread Luis R. Rodriguez
On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote: > On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote: >> >>> On 12.06.15 at 01:23, wrote: >> > There are two usages on MTRRs: >> > 1) MTRR entries set by firmware >> > 2) MTRR entries set by OS drivers >> > >> > We can obsolete 2), but we hav

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-06-14 Thread Jan Beulich
>>> On 13.06.15 at 01:15, wrote: > On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote: >> >> >>> On 12.06.15 at 01:23, wrote: >> > There are two usages on MTRRs: >> > 1) MTRR entries set by firmware >> > 2) MTRR entries set by OS drivers >> > >> > We can obsolete 2), but we have no control over 1).

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-06-12 Thread Ingo Molnar
* Andy Lutomirski wrote: > On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote: > > > > >>> On 12.06.15 at 01:23, wrote: > > > There are two usages on MTRRs: > > > 1) MTRR entries set by firmware > > > 2) MTRR entries set by OS drivers > > > > > > We can obsolete 2), but we have no control over 1)

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-06-12 Thread James Bottomley
On Fri, 2015-06-12 at 16:15 -0700, Andy Lutomirski wrote: > On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote: > > > > >>> On 12.06.15 at 01:23, wrote: > > > There are two usages on MTRRs: > > > 1) MTRR entries set by firmware > > > 2) MTRR entries set by OS drivers > > > > > > We can obsolete 2),

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-06-12 Thread Andy Lutomirski
On Jun 12, 2015 12:59 AM, "Jan Beulich" wrote: > > >>> On 12.06.15 at 01:23, wrote: > > There are two usages on MTRRs: > > 1) MTRR entries set by firmware > > 2) MTRR entries set by OS drivers > > > > We can obsolete 2), but we have no control over 1). As UEFI firmwares > > also set this up, t

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-06-12 Thread Toshi Kani
On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote: > >>> On 12.06.15 at 01:23, wrote: > > There are two usages on MTRRs: > > 1) MTRR entries set by firmware > > 2) MTRR entries set by OS drivers > > > > We can obsolete 2), but we have no control over 1). As UEFI firmwares > > also set this

Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

2015-06-12 Thread Jan Beulich
>>> On 12.06.15 at 01:23, wrote: > There are two usages on MTRRs: > 1) MTRR entries set by firmware > 2) MTRR entries set by OS drivers > > We can obsolete 2), but we have no control over 1). As UEFI firmwares > also set this up, this usage will continue to stay. So, we should not > get rid o