[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.