[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110524153614.GA19080@linux-youquan.bj.intel.com>
Date: Tue, 24 May 2011 11:36:14 -0400
From: Youquan Song <youquan.song@...ux.intel.com>
To: Valdis.Kletnieks@...edu
Cc: Youquan Song <youquan.song@...el.com>,
linux-kernel@...r.kernel.org, david.woodhouse@...el.com,
akpm@...ux-foundation.org, mingo@...e.hu, tglx@...utronix.de,
hpa@...or.com, hpa@...ux.intel.com, allen.m.kay@...el.com,
suresh.b.siddha@...el.com, rajesh.sankaran@...el.com,
asit.k.mallick@...el.com, kent.liu@...el.com,
Youquan Song <youquan.song@...ux.intel.com>
Subject: Re: [PATCH v3] x86, vt-d: enable x2apic opt out
> If we're doing a WARN level here, what are the downsides of just automagically
> forcing it rather than making them use a kernel parameter and reboot?
As we have discussed before, x2apci opt out feature is requested from OEM that
they want to firmware tell OS to opt out x2apic when the platform,
hardware or BIOS is not ready to support x2apic. So we can not reboot or
force to use kernel parameter.
But as David Woodhouse address that there are some researches about
disabling x2apic will be vulnerable to irq-injection attack, so we need
warn user about it. If user is sensitive to it, they also has alternative
choice to ignore BIOS request by adding no_x2apic_optout kernel parameter.
> Will some systems fail to boot because the BIOS was in fact right in requesting
No. we do not want system boot fail for BIOS requesting it.
Thanks
-Youquan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists