On 27/01/16 10:22, Jan Beulich wrote: >>>> On 26.01.16 at 23:35, <kevin.t...@intel.com> wrote: >>> From: Jan Beulich [mailto:jbeul...@suse.com] >>> 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 <jbeul...@suse.com> >> Acked-by: Kevin Tian <kevin.t...@intel.com> 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@lists.xen.org http://lists.xen.org/xen-devel
