xen-devel
RE: [Xen-devel] RE: [Xen-changelog] [xen-unstable]vt-d: Fixpanic in msi_
Keir Fraser wrote:
> On 19/10/2009 12:51, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>
>>> Got a backtrace and Xen boot params? If you pass acpi=off, then
>>> disable_acpi() is invoked, and this sets acpi_disabled. If
>>> acpi_disabled=1, then iommu_setup() sets iommu_enabled=0. If
>>> iommu_enabled=0 then I think all the update_ire_from_* and similar
>>> hooks get disabled in the callers. So something unexpected must be
>>> happening.
>>
>> Hmmm, perhaps this could be an early boot-time crash before
>> iommu_setup() is even called? Perhaps moving the if(acpi_disabled)
>> iommu_enabled=0 somewhere early-ish in setup.c:__start_xen(), with a
>> warning message, would be the right thing to do in that case (e.g.,
>> immediately after the call to cmdline_parse()).
>
> After some more hmmm'ing I have to admit your original patch was
> actually the best way to go. :-)
>
> All other callers of acpi_find_matched_drhd_unit() that you didn't
> patch already check for NULL return, so it's presumably expected as a
> possibility. And it is okay for msi_msg_{read,write}_remap_rte() to
> bail silently if they cannot determine there's any work to do, since
> they operate as potential modifiers to operations which are primarily
> implemented in their callers.
>
> So sorry about that. I'll revert Dexuan's patch.
>
> -- Keir
But, can't you reproduce the crash I mentioned before?
Please see the attached crash log -- I'm using c/s 20341:ea34183c5c11 and with
"iommu=1 acpi=off" and I use a DQ35 host.
Actually what I care is the " if ( acpi_disabled ) iommu_enabled = 0".
Thanks,
-- Dexuan
crash.log
Description: crash.log
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|