[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] dom0 / hypervisor hang on dom0 boot

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, May 21, 2013 4:04 PM
> >>> On 20.05.13 at 16:30, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>
> wrote:
> > The only trick for i915 in dom0, in my mind, is to have CONFIG_DMAR enabled
> in
> > dom0 although dom0 is not actually exposed with a VT-d engine. This sets
> need_dmar
> > flag in i915, ensures i915 to use Xen DMA interface instead of virt_to_phys,
> so that
> > MFN is written to GTT entries. Otherwise, having GPFN in GTT entries is
> bogus, since
> > GPU will DMA to wrong locations then, and thus cause random issues.
> Enabling CONFIG_DMAR (or really CONFIG_INTEL_IOMMU in recent
> kernels) is not an option. However, we patch all respective sites to
> also take effect on Xen (of course that doesn't help pv-ops, but here
> we're talking about a forward ported kernel anyway).

could you elaborate why CONFIG_DMAR is not an option? we still use it at least
on 3.8 series kernel.

if you have already patched all the address translation codes in i915 driver, 
where need_dmar is checked, yes this looks not a reason.

> > Once we also identified a regression in 3.8, where need_dmar is not honored
> in
> > i915 driver:
> Dietmar had already tested with 3.9, so this ought to not affect
> him.

no much idea then. For random issues with Intel gfx card in a virtualization 
normally GTT is the most likely problem, and then comes the cache attributes of 
i915 buffer objects. However I don't remember any recent issue related to cache


Xen-devel mailing list



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