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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> 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, 
i.e.
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 
world,
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
side...

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel