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

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0



>>> On 17.02.17 at 07:53, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Tian, Kevin
>> Sent: Friday, February 17, 2017 11:35 AM
>> > >>
>> > >> Or wait - do you have the same issue if you use
>> > >> "iommu=no,no-intremap"? In which case the problem would be
>> > >> that "iommu=no" should clear more than just "iommu_enable", or
>> > >> code checking iommu_intremap early (before iommu_setup()
>> > >> manages to clear it in the case here) would need to made look at
>> > >> both variables. Oddly enough acpi_parse_dmar() only bails if
>> > >> both variables are clear, which suggests to me that
>> > >> iommu_enable is intended to have two different meanings in
>> > >> different contexts (master flag vs. controlling just DMA
>> > >> remapping). Kevin, Feng - any thoughts here?
>> > >
>> > > iommu=no,no-intremap boots fine with "(XEN) Using APIC driver default"
>> >
>> > Thanks for confirming.
>> >
>> > Kevin, Feng, we now depend on your input regarding the intentions
>> > with the two variables.
>> >
>> 
>> Feng just left Intel. Let me take a look at code to understand the
>> rationale behind.
>> 
> 
> Jan, looks it's caused by your change back to 2012:
> 
> commit 7a8f6d0607a38c64506b4e8b473d955bf8e2a71f
> Author: Jan Beulich <jbeulich@xxxxxxxx>
> Date:   Fri Nov 2 17:15:30 2012 +0100

Oh, I see. That's been a while; I'm sorry for not having remembered
and bugging you.

> Before that iommu_enable was the master flag consistently. I'm still
> trying to understand the background and you may help elaborate if
> still something in your memory.

I think the commit description is pretty clear. Especially this part

"This could have the nice side effect of allowing to use "iommu=off"
 even when x2APIC was pre-enabled by the BIOS (in which case interrupt
 remapping is a requirement, but DMA translation [obviously] isn't), but
 that doesn't currently work (and hence x2apic_bsp_setup() forces the
 IOMMU on rather than just interrupt remapping)."

is quite relevant in the context here. Just like Linux, we really ought
to have a way to run with interrupt remapping, but without DMA
remapping. So I think this old commit was a half-hearted step into
that direction, not recognizing that it would break some other case.

So I think the only reasonable way forward to address Tamas's
issue is to fully disentangle DMA and interrupt remapping setup,
which I'm sure is going to take some time. As a minimal adjustment,
though, I wonder whether that old commit's adjustment to apic.c
shouldn't rather have set force_intremap. Tamas - could you check
whether

--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -975,7 +975,7 @@ void __init x2apic_bsp_setup(void)
         goto restore_out;
     }
 
-    force_iommu = 1;
+    force_intremap = 1;
 
     genapic = apic_x2apic_probe();
     printk("Switched to APIC driver %s.\n", genapic->name);

makes things any better?

Jan


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

 


Rackspace

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