Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-10 Thread George Dunlap
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"

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-10 Thread Ian Campbell
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

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-09 Thread Jan Beulich
>>> 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) -

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-09 Thread George Dunlap
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, >>>

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-09 Thread Jan Beulich
>>> 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

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-09 Thread George Dunlap
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

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-09 Thread Jan Beulich
>>> 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

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-08 Thread George Dunlap
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

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-02 Thread Jan Beulich
>>> 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

Re: [Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-02 Thread Andrew Cooper
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

[Xen-devel] [PATCH v7] x86/p2m: use large pages for MMIO mappings

2016-02-02 Thread Jan Beulich
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