Hi David,
Today's linux-next merge of the dwmw2-iommu tree got a conflict in
arch/x86/kernel/apic/apic.c between commit 31dce14a3269 ("x86, ioapic:
Use ioapic_saved_data while enabling intr-remapping") from Linus' tree and
commit 6a87c5ec6463 ("intel-iommu: enable x2apic opt out") from the
dwmw2-iommu tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell [email protected]
diff --cc arch/x86/kernel/apic/apic.c
index b961af8,fb1c36c..0000000
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@@ -1461,16 -1450,24 +1461,17 @@@ int __init enable_IR(void
void __init enable_IR_x2apic(void)
{
unsigned long flags;
- int ret, x2apic_enabled = 0;
- struct IO_APIC_route_entry **ioapic_entries;
+ int ret = 0, x2apic_enabled = 0;
int dmar_table_init_ret;
dmar_table_init_ret = dmar_table_init();
- if (dmar_table_init_ret && !x2apic_supported())
+ if (dmar_table_init_ret && !cpu_has_x2apic)
return;
- ioapic_entries = alloc_ioapic_entries();
- if (!ioapic_entries) {
- pr_err("Allocate ioapic_entries failed\n");
- goto out;
- }
-
- ret = save_IO_APIC_setup(ioapic_entries);
+ ret = save_ioapic_entries();
if (ret) {
pr_info("Saving IO-APIC state failed: %d\n", ret);
+ ret = 0;
goto out;
}
* Stephen Rothwell <[email protected]> wrote:
> Hi David,
>
> Today's linux-next merge of the dwmw2-iommu tree got a conflict in
> arch/x86/kernel/apic/apic.c between commit 31dce14a3269 ("x86, ioapic:
> Use ioapic_saved_data while enabling intr-remapping") from Linus' tree and
> commit 6a87c5ec6463 ("intel-iommu: enable x2apic opt out") from the
> dwmw2-iommu tree.
David, please do not modify arch/x86/kernel/apic/apic.c but send such
patches to the x86 maintainers!
That particular change was still under discussion and i'm not at all
sure we want to do it like that. So please repost the latest version.
Thanks,
Ingo
On Wed, 25 May 2011, Ingo Molnar wrote:
> That particular change was still under discussion and i'm not at all
> sure we want to do it like that. So please repost the latest version.
I had not seen such discussion; I had the impression that having dealt
with my feedback about making the thing more visible to the user, Youquan
considered the patch complete.
I am more than happy to absolve responsibility for this patch altogether
and drop it from tree, though. It is *absolutely* the wrong approach, in
my opinion. If the BIOS is broken and cannot cope with x2apic, the
solution is to line the "engineers" responsible up against the wall and
shoot them. And then to implement a "quiesce all SMI" feature that the OS
can invoke, and make it mandatory. Presumably that's the underlying
problem they were trying to solve?
The answer certainly isn't to add a flag in the DMAR table to opt out of
x2apic use, when afaict the kernel is capable of using x2apic in some
cases even when the *is* no DMAR. (Either that, or we have a lot of dead
code in that area which *looks* like it copes with x2apic+!dmar).
I'll drop this patch from my tree when I get home and happily wash my
hands of it. It's all yours; have fun :)
--
dwmw2
* David Woodhouse <[email protected]> wrote:
> On Wed, 25 May 2011, Ingo Molnar wrote:
>
> > That particular change was still under discussion and i'm not at all
> > sure we want to do it like that. So please repost the latest version.
>
> I had not seen such discussion; I had the impression that having dealt
> with my feedback about making the thing more visible to the user, Youquan
> considered the patch complete.
I lurked your discussion with Youquan and expected another iteration
posted. I was keeping my gun powder dry for the next round because i
saw you reaping the patch to pieces already and there was nothing
more to say really :)
> I am more than happy to absolve responsibility for this patch
> altogether and drop it from tree, though. It is *absolutely* the
> wrong approach, in my opinion. If the BIOS is broken and cannot
> cope with x2apic, the solution is to line the "engineers"
> responsible up against the wall and shoot them. And then to
> implement a "quiesce all SMI" feature that the OS can invoke, and
> make it mandatory. Presumably that's the underlying problem they
> were trying to solve?
>
> The answer certainly isn't to add a flag in the DMAR table to opt
> out of x2apic use, when afaict the kernel is capable of using
> x2apic in some cases even when the *is* no DMAR. (Either that, or
> we have a lot of dead code in that area which *looks* like it copes
> with x2apic+!dmar).
Yeah, that was exactly my main concern as well: why should we allow
the BIOS to tell us not to use a CPU feature that the CPU tells us is
usable?
We generally do not allow such level of BIOS control. They should fix
the BIOS to not generate DMAR tables at all if they want us to 'opt
out', or ship a CPU without x2apic (or a CPU microcode version that
turns off the x2apic CPUID bit or whatever).
So unless i missed some fine detail of control here, the whole idea
of generating DMAR tables (which were always inherently connected to
x2apic really) that tell us 'never mind about x2apic!' seems rather
counter-productive ...
> I'll drop this patch from my tree when I get home and happily wash
> my hands of it. It's all yours; have fun :)
Thanks. Youquan, mind resending the latest and greatest version so we
can continue flami^W iterating it? Please also Cc: David.
Thanks,
Ingo
On Wed, May 25, 2011 at 01:00:04PM +1000, Stephen Rothwell wrote:
> Hi David,
>
> Today's linux-next merge of the dwmw2-iommu tree got a conflict in
> arch/x86/kernel/apic/apic.c between commit 31dce14a3269 ("x86, ioapic:
> Use ioapic_saved_data while enabling intr-remapping") from Linus' tree and
> commit 6a87c5ec6463 ("intel-iommu: enable x2apic opt out") from the
> dwmw2-iommu tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
The fix looks good to me.
Thanks
-Youquan
On Wed, 2011-05-25 at 13:00 +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the dwmw2-iommu tree got a conflict in
> arch/x86/kernel/apic/apic.c between commit 31dce14a3269 ("x86, ioapic:
> Use ioapic_saved_data while enabling intr-remapping") from Linus' tree and
> commit 6a87c5ec6463 ("intel-iommu: enable x2apic opt out") from the
> dwmw2-iommu tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Offending patch dropped.
The machine hosting git.infradead.org is going down shortly, and will be
coming up in a new home tomorrow morning Boston time (EDT/GMT-5). Please
could you use this git repository instead for the iommu tree, for
"tonight's" linux-next:
git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/iommu-2.6.git
(or ssh://master.kernel.org/pub/scm/linux/kernel/git/dwmw2/iommu-2.6.git
if it hasn't propagated to the mirrors in time)
Thanks.
The mtd tree hasn't changed in the last day, so no need to use a
separate URL for that; the last pull is fine, right?
--
dwmw2