linux-kernel - Re: [RFC PATCH v4 21/21] x86/watchdog/hardlockup/hpet: Support interrupt remapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1906161051491.1760@nanos.tec.linutronix.de>
Date:   Sun, 16 Jun 2019 10:53:33 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
cc:     Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        Ashok Raj <ashok.raj@...el.com>,
        Joerg Roedel <joro@...tes.org>,
        Andi Kleen <andi.kleen@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
        Stephane Eranian <eranian@...gle.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Randy Dunlap <rdunlap@...radead.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
        Ricardo Neri <ricardo.neri@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Jacob Pan <jacob.jun.pan@...el.com>,
        Juergen Gross <jgross@...e.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Wincy Van <fanwenyi0529@...il.com>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Baoquan He <bhe@...hat.com>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        Lu Baolu <baolu.lu@...ux.intel.com>
Subject: Re: [RFC PATCH v4 21/21] x86/watchdog/hardlockup/hpet: Support
 interrupt remapping

On Sun, 16 Jun 2019, Thomas Gleixner wrote:

> On Thu, 23 May 2019, Ricardo Neri wrote:
> > +/** irq_remapping_enabled() - Detect if interrupt remapping is enabled
> > + * @hdata:	A data structure with the HPET block id
> > + *
> > + * Determine if the HPET block that the hardlockup detector is under
> > + * the remapped interrupt domain.
> > + *
> > + * Returns: True interrupt remapping is enabled. False otherwise.
> > + */
> > +static bool irq_remapping_enabled(struct hpet_hld_data *hdata)
> > +{
> > +	struct irq_alloc_info info;
> > +
> > +	init_irq_alloc_info(&info, NULL);
> > +	info.type = X86_IRQ_ALLOC_TYPE_HPET;
> > +	info.hpet_id = hdata->blockid;
> > +
> > +	return !!irq_remapping_get_ir_irq_domain(&info);
> > +}
> > +
> >  /**
> >   * compose_msi_msg() - Populate address and data fields of an MSI message
> >   * @hdata:	A data strucure with the message to populate
> > @@ -161,6 +181,9 @@ static int update_msi_destid(struct hpet_hld_data *hdata)
> >  {
> >  	u32 destid;
> >  
> > +	if (irq_remapping_enabled(hdata))
> > +		return hld_hpet_intremap_activate_irq(hdata);
> 
> No. This is horrible hackery violating all the layering which we carefully
> put into place to avoid exactly this kind of sprinkling conditionals into
> all code pathes.
> 
> With some thought the existing irqdomain hierarchy can be used to achieve
> the same thing without tons of extra functions and conditionals.

And of course this whole thing falls completely apart when someone enables
the hpet watchdog on AMD.

Can you folks please stop this works for me tinkering and finally grasp
that there is a world outside of Intel and outside of big enterprise boxes?

Thanks,

	tglx