lkml.org 
[lkml]   [2013]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] irq: add quirk for broken interrupt remapping on 55XX chipsets
    On Thu, Apr 04, 2013 at 11:14:30AM -0600, Bjorn Helgaas wrote:
    > On Thu, Apr 4, 2013 at 9:39 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
    > > On Thu, Apr 04, 2013 at 08:57:06AM -0600, Bjorn Helgaas wrote:
    > >> On Thu, Apr 4, 2013 at 8:50 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
    > >> > On Thu, Apr 04, 2013 at 03:27:29PM +0100, David Woodhouse wrote:
    > >> >> On Wed, 2013-04-03 at 17:53 -0600, Bjorn Helgaas wrote:
    > >> >> > );
    > >> >> > > +
    > >> >> > > + if ((revision == 0x13) && irq_remapping_enabled) {
    > >> >> > > + pr_warn(HW_ERR "This system BIOS has enabled interrupt remapping\n"
    > >> >> > > + "on a chipset that contains an errata making that\n"
    > >> >> > > + "feature unstable. Please reboot with nointremap\n"
    > >> >> > > + "added to the kernel command line and contact\n"
    > >> >> > > + "your BIOS vendor for an update");
    > >> >>
    > >> >> This should be WARN_TAINT(TAINT_FIRMWARE_WORKAROUND). And 'an erratum'.
    > >> >>
    > >> > Ok, copy that. I'll repost shortly
    > >>
    > >> When you do, please include URLs for any problem reports or bugzillas you have.
    > >>
    > > Well, those are going to be vendor specific, so I'm not sure we can really do
    > > that, at least not in any meaningful way.
    >
    > Sorry, I don't understand your point. It's useful to know who
    > reported it (e.g., for future testers) and what happened and what
    > bugzillas it solved. Of course it applies only to machines with this
    > chipset and certain BIOS revisions.
    >
    Oh, you want the bug report that I'm fixing this against? Sure, I can do that.
    I thought you wanted me to include a url in the WARN_TAINT, with which user
    could report occurances of this bug. Yeah, the bug that this is reported in is:
    https://bugzilla.redhat.com/show_bug.cgi?id=887006

    Its standing in for about a dozen or so variants of this issue we've seen

    > >> I assume Windows "just works" in this situation?
    > > No more or less than linux does in this case. The Intel provided errata
    > > indicates that the only acceptable workaround is to disable remapping in the
    > > BIOS, so I would presume that if a windows system has a BIOS that doesn't
    > > implement this fix, its just as exposed as we are.
    >
    > It sounds like the effect of this bug is that on Linux, devices may
    > not work at all because of lost interrupts. Either Windows must never
    > enable remapping (so it never sees the bug), or it must be designed in
    > a way that tolerates the problem. I can't believe these machines
    > shipped with Windows certification if devices didn't work correctly.
    >
    I don't know what to tell you here. We explicitly asked intel about this, and
    there was an effort to recode the interrupt migration code to properly manage
    this situation, and intels response was "No, just disable it in BIOS", so we're
    telling people to disable it in BIOS. You'd have to ask somebody at Microsoft
    what Windows did or did not do about this problem.

    > Either way, I don't understand why we can't make the quirk just fix
    > this. Booting with "nointremap" only sets disable_irq_remap, which is
    > only used by irq_remapping_supported(). Early quirks are run before
    > irq_remapping_supported () is ever called, so an early quirk ought to
    > be just as effective as the command line option. Here's the relevant
    > call tree I see:
    >
    > start_kernel
    > setup_arch
    > parse_early_param
    > early_quirks
    > rest_init
    > ...
    > <first use of disable_irq_remap>
    >
    > The x86 setup_arch() does call generic_apic_probe(), but as far as I
    > can tell, none of the APIC .probe() methods reference
    > disable_irq_remap, so that doesn't look like a problem.
    >
    Well, I can give it a try, but I'm sure something went wrong last time I did.
    Regardless, theres also the security issue to consider here - namely that
    disabling irq remapping opens up users of virt to a possible security bug
    (potential irq injection). Some users may wish to live with the remapping
    error, given that error typically leads to devices that need to be
    restarted/reset to start working again, rather than live with the security hole.
    I rather like the warning, that gives users a choice, but I'll spin up a version
    that just disables it if you would rather.

    Neil



    \
     
     \ /
      Last update: 2013-04-04 21:03    [W:2.411 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site