On 10/02/16 10:06, Ian Campbell wrote:
> On Tue, 2016-02-09 at 05:35 -0700, Jan Beulich wrote:
>>> On 09.02.16 at 13:17, wrote:
>>> I don't think sometimes returning the number of things you did and
>>> sometimes returning zero makes any sense. My suggestion would be
>>> either
>>> make "nr_mfns"
On Tue, 2016-02-09 at 05:35 -0700, Jan Beulich wrote:
> > On 09.02.16 at 13:17, wrote:
> > I don't think sometimes returning the number of things you did and
> > sometimes returning zero makes any sense. My suggestion would be
> > either
> > make "nr_mfns" bidirectional (as similar fields are in
>>> On 09.02.16 at 13:17, wrote:
> On 09/02/16 11:48, Jan Beulich wrote:
> On 09.02.16 at 11:56, wrote:
>>> On 09/02/16 08:42, Jan Beulich wrote:
>>> On 08.02.16 at 19:04, wrote:
> First -- and this isn't a blocker, but just a question (and sorry if
> it's been answered before) -
On 09/02/16 11:48, Jan Beulich wrote:
On 09.02.16 at 11:56, wrote:
>> On 09/02/16 08:42, Jan Beulich wrote:
>> On 08.02.16 at 19:04, wrote:
First -- and this isn't a blocker, but just a question (and sorry if
it's been answered before) -- why have the "0 means I did it all, >>>
>>> On 09.02.16 at 11:56, wrote:
> On 09/02/16 08:42, Jan Beulich wrote:
> On 08.02.16 at 19:04, wrote:
>>> First -- and this isn't a blocker, but just a question (and sorry if
>>> it's been answered before) -- why have the "0 means I did it all, >> means I did it partially"? Why not just re
On 09/02/16 08:42, Jan Beulich wrote:
On 08.02.16 at 19:04, wrote:
>> First -- and this isn't a blocker, but just a question (and sorry if
>> it's been answered before) -- why have the "0 means I did it all, > means I did it partially"? Why not just return the number of entries
>> actually h
>>> On 08.02.16 at 19:04, wrote:
> First -- and this isn't a blocker, but just a question (and sorry if
> it's been answered before) -- why have the "0 means I did it all, means I did it partially"? Why not just return the number of entries
> actually handled?
Because I view zero as the convent
On 02/02/16 15:15, 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 once again, so
>>> On 02.02.16 at 16:27, wrote:
> On 02/02/16 15:15, Jan Beulich wrote:
>> @@ -2095,6 +2131,30 @@ void *map_domain_gfn(struct p2m_domain *
>> return map_domain_page(*mfn);
>> }
>>
>> +static unsigned int mmio_order(const struct domain *d,
>> + unsigned long s
On 02/02/16 15:15, Jan Beulich wrote:
> @@ -2095,6 +2131,30 @@ void *map_domain_gfn(struct p2m_domain *
> return map_domain_page(*mfn);
> }
>
> +static unsigned int mmio_order(const struct domain *d,
> + unsigned long start_fn, unsigned long nr)
> +{
> +if
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 once again, so that there's no
longer a fixed amount of guest
11 matches
Mail list logo
