On Mon, 2016-01-25 at 07:16 -0700, Jan Beulich wrote:
> > > > On 25.01.16 at 15:05, wrote:
> > On Mon, 2016-01-25 at 06:54 -0700, Jan Beulich wrote:
> > > > > > On 25.01.16 at 13:16, wrote:
> > > > On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
> > > > > +#define MAP_MMIO_MAX_ITER 64 /* pr
>>> On 25.01.16 at 15:05, wrote:
> On Mon, 2016-01-25 at 06:54 -0700, Jan Beulich wrote:
>> > > > On 25.01.16 at 13:16, wrote:
>> > On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
>> > > +#define MAP_MMIO_MAX_ITER 64 /* pretty arbitrary */
>> > > +
>> >
>> > I suppose no existing in-tree c
On Mon, 2016-01-25 at 06:54 -0700, Jan Beulich wrote:
> > > > On 25.01.16 at 13:16, wrote:
> > On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
> > > +#define MAP_MMIO_MAX_ITER 64 /* pretty arbitrary */
> > > +
> >
> > I suppose no existing in-tree code exceeds that (or there'd be more
> > p
>>> On 25.01.16 at 13:16, wrote:
> On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
>> +#define MAP_MMIO_MAX_ITER 64 /* pretty arbitrary */
>> +
>
> I suppose no existing in-tree code exceeds that (or there'd be more patch
> here).
There simply is no in-tree user other than the domctl on x8
On Fri, 2016-01-22 at 08:42 -0700, Jan Beulich wrote:
> When mapping large BARs (e.g. the frame buffer of a graphics card) the
> overhead of establishing such mappings using only 4k pages has,
> particularly after the XSA-125 fix, become unacceptable. Alter the
> XEN_DOMCTL_memory_mapping semantics
