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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.05.13 at 10:28, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>  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.

Because this enables a bunch of dead code that in our Xen kernel
we want to be sure is dead (i.e. not becoming reachable all of the
sudden by some code path added without us noticing).
Consequently INTEL_IOMMU depends on !XEN, and there's no
intention to change this.

> 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.

All the places under drivers/char/agp/ and drivers/gpu/drm/i915/
that reference CONFIG_INTEL_IOMMU, and the declaration of
intel_iommu_gfx_mapped is a #define to 1 under CONFIG_XEN.

Jan


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