[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |