[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5] x86/p2m: use large pages for MMIO mappings
On 27/01/16 10:22, Jan Beulich wrote: >>>> On 26.01.16 at 23:35, <kevin.tian@xxxxxxxxx> wrote: >>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx] >>> Sent: Tuesday, January 26, 2016 12:19 AM >>> >>> 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 frames that represents the upper limit >>> of what a single invocation can map. Instead bound execution time by >>> limiting the number of iterations (regardless of page size). >>> >>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> for VMX part. >> >> Curious. When you say "become unacceptable", how bad is it? mostly >> impact the boot time? > Yes, guest boot time. I don't have a reference to the original report > at hand, but that was what someone (Konrad?) had reported. I've > never seen the issue myself, largely because I've never made any > attempt at GPU pass-through. From XenServer testing, with a 1GB GPU BAR, XSA-125 caused and additional 70s of guest boot time. Naturally. we had to work around this. Partly upping the repeat limit, and deferring VT-d flushes. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |