linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <ak@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	"Schlobohm, Bruce" <bruce.schlobohm@intel.com>,
	"Kovatch, Kathleen" <kathleen.kovatch@intel.com>
Cc: Kuppuswamy Sathyanarayanan 
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Andy Lutomirski <luto@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Richard Henderson <rth@twiddle.net>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	James E J Bottomley <James.Bottomley@hansenpartnership.com>,
	Helge Deller <deller@gmx.de>,
	"David S . Miller" <davem@davemloft.net>,
	Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
	Paolo Bonzini <pbonzini@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter H Anvin <hpa@zytor.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Tony Luck <tony.luck@intel.com>,
	Kirill Shutemov <kirill.shutemov@linux.intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
	X86 ML <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PCI <linux-pci@vger.kernel.org>,
	linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	virtualization@lists.linux-foundation.org, "Reshetova,
	Elena" <elena.reshetova@intel.com>
Subject: Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()
Date: Mon, 18 Oct 2021 03:10:21 +0200	[thread overview]
Message-ID: <871r4j2l4y.ffs@tglx> (raw)
In-Reply-To: <875ytv2lu8.ffs@tglx>

On Mon, Oct 18 2021 at 02:55, Thomas Gleixner wrote:
> On Sun, Oct 10 2021 at 15:11, Andi Kleen wrote:
>> The 5.15 tree has something like ~2.4k IO accesses (including MMIO and 
>> others) in init functions that also register drivers (thanks Elena for 
>> the number)
>
> These numbers are completely useless simply because they are based on
> nonsensical criteria. See:
>
>   https://lore.kernel.org/r/87r1cj2uad.ffs@tglx
>
>> My point is just that the ecosystem of devices that Linux supports is 
>> messy enough that there are legitimate exceptions from the "First IO 
>> only in probe call only" rule.
>
> Your point is based on your outright refusal to actualy do a proper
> analysis and your outright refusal to help fixing the real problems.
>
> All you have provided so far is handwaving based on a completely useless
> analysis.
>
> Sure, your goal is to get this TDX problem solved, but it's not going to
> be solved by:
>
>   1) Providing a nonsensical analysis
>
>   2) Using #1 as an argument to hack some half baken interfaces into the
>      kernel which allow you to tick off your checkbox and then leave the
>      resulting mess for others to clean up.
>  
> Try again when you have factual data to back up your claims and factual
> arguments which prove that the problem can't be fixed otherwise.
>
> I might be repeating myself, but kernel development works this way:
>
>   1) Hack your private POC - Yay!
>
>   2) Sit down and think hard about the problems you identified in step
>      #1. Do a thorough analysis.
>   
>   3) Come up with a sensible integration plan.
>
>   4) Do the necessary grump work of cleanups all over the place
>
>   5) Add sensible infrastructure which is understandable for the bulk
>      of kernel/driver developers
>
>   6) Let your feature fall in place
>
> and not in the way you are insisting on:
>
>   1) Hack your private POC - Yay!
>
>   2) Define that this is the only way to do it and try to shove it down
>      the throat of everyone.
>
>   3) Getting told that this is not the way it works
>
>   4) Insist on it forever and blame the grumpy maintainers who are just
>      not understanding the great value of your approach.
>
>   5) Go back to #2
>
> You should know that already, but I have no problem to give that lecture
> to you over and over again. I probably should create a form letter.
>
> And no, you can bitch about me as much as you want. These are not my
> personal rules and personal pet pieves. These are rules Linus cares
> about very much and aside of that they just reflect common sense.
>
>   The kernel is a common good and not the dump ground for your personal
>   brain waste.
>
>   The kernel does not serve Intel. Quite the contrary Intel depends on
>   the kernel to work nicely with it's hardware. Ergo, Intel should have
>   a vested interest to serve the kernel and take responsibility for it
>   as a whole. And so should you as an Intel employee.
>
> Just dumping your next half baken workaround does not cut it especially
> not when it is not backed up by sensible arguments.
>
> Please try again, but not before you have something substantial to back
> up your claims.

That said, I can't resist the urge to say a few words to the responsible
senior and management people at Intel in this context:

I surely know that a lot of Intel people claim that their lack of
progress is _only_ because Thomas is hard to work with and Thomas wants
unreasonable changes to their code, which I could perceive as an abuse of
myself for the purpose of self-deception. TBH, I don't give a damn.

Let me ask a few questions instead:

  - Is it unreasonable to expect that argumentations are based on facts
    and proper analysis?

  - Is it unreasonable to expect a proper integration of a new feature?

  - Does it take unreasonable effort to do a proper design?

  - Is it unreasonable to ask that he necessary cleanups are done
    upfront?

If anyone of the responsible people at Intel thinks so, then they should
speak up now and tell me in public and into my face what's so
unreasonable about that.

Thanks,

	Thomas

  reply	other threads:[~2021-10-18  1:10 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-09  0:36 [PATCH v5 00/16] Add TDX Guest Support (shared-mm support) Kuppuswamy Sathyanarayanan
2021-10-09  0:36 ` [PATCH v5 01/16] x86/mm: Move force_dma_unencrypted() to common code Kuppuswamy Sathyanarayanan
2021-10-20 16:11   ` Tom Lendacky
2021-10-20 16:43     ` Sathyanarayanan Kuppuswamy
2021-10-09  0:36 ` [PATCH v5 02/16] x86/tdx: Get TD execution environment information via TDINFO Kuppuswamy Sathyanarayanan
2021-10-09  0:36 ` [PATCH v5 03/16] x86/tdx: Exclude Shared bit from physical_mask Kuppuswamy Sathyanarayanan
2021-11-05 22:11   ` Sean Christopherson
2021-11-08 14:45     ` Kirill A. Shutemov
2021-10-09  0:36 ` [PATCH v5 04/16] x86/tdx: Make pages shared in ioremap() Kuppuswamy Sathyanarayanan
2021-10-20 16:03   ` Tom Lendacky
2021-10-20 16:41     ` Sathyanarayanan Kuppuswamy
2021-10-09  0:37 ` [PATCH v5 05/16] x86/tdx: Add helper to do MapGPA hypercall Kuppuswamy Sathyanarayanan
2021-10-09  0:37 ` [PATCH v5 06/16] x86/tdx: Make DMA pages shared Kuppuswamy Sathyanarayanan
2021-10-20 16:33   ` Tom Lendacky
2021-10-20 16:45     ` Sathyanarayanan Kuppuswamy
2021-10-20 17:22       ` Tom Lendacky
2021-10-20 17:26         ` Sathyanarayanan Kuppuswamy
2021-10-09  0:37 ` [PATCH v5 07/16] x86/kvm: Use bounce buffers for TD guest Kuppuswamy Sathyanarayanan
2021-10-20 16:39   ` Tom Lendacky
2021-10-20 16:50     ` Sathyanarayanan Kuppuswamy
2021-10-20 17:26       ` Tom Lendacky
2021-10-09  0:37 ` [PATCH v5 08/16] x86/tdx: ioapic: Add shared bit for IOAPIC base address Kuppuswamy Sathyanarayanan
2021-10-09  0:37 ` [PATCH v5 09/16] x86/tdx: Enable shared memory confidential guest flags for TDX guest Kuppuswamy Sathyanarayanan
2021-10-09  0:37 ` [PATCH v5 10/16] PCI: Consolidate pci_iomap_range(), pci_iomap_wc_range() Kuppuswamy Sathyanarayanan
2021-10-09  0:37 ` [PATCH v5 11/16] asm/io.h: Add ioremap_host_shared fallback Kuppuswamy Sathyanarayanan
2021-10-09  0:37 ` [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range() Kuppuswamy Sathyanarayanan
2021-10-09  9:53   ` Michael S. Tsirkin
2021-10-09 20:39     ` Dan Williams
2021-10-10 22:11       ` Andi Kleen
2021-10-12 17:42         ` Dan Williams
2021-10-12 18:35           ` Andi Kleen
2021-10-12 21:14             ` Dan Williams
2021-10-12 21:18               ` Michael S. Tsirkin
2021-10-12 21:24                 ` Andi Kleen
2021-10-12 21:28               ` Andi Kleen
2021-10-12 22:00                 ` Dan Williams
2021-10-18 12:13             ` Greg KH
2021-10-12 18:36         ` Reshetova, Elena
2021-10-12 18:38           ` Andi Kleen
2021-10-12 18:57             ` Reshetova, Elena
2021-10-12 19:13               ` Dan Williams
2021-10-12 19:49                 ` Andi Kleen
2021-10-12 21:11           ` Michael S. Tsirkin
2021-10-14  6:32             ` Reshetova, Elena
2021-10-14  6:57               ` Michael S. Tsirkin
2021-10-14  7:27                 ` Reshetova, Elena
2021-10-14  9:26                   ` Michael S. Tsirkin
2021-10-14 12:33                     ` Reshetova, Elena
2021-10-17 22:17                       ` Michael S. Tsirkin
2021-10-14 11:49                   ` Michael S. Tsirkin
2021-10-17 21:52               ` Thomas Gleixner
2021-10-18  7:03                 ` Reshetova, Elena
2021-10-18  0:55         ` Thomas Gleixner
2021-10-18  1:10           ` Thomas Gleixner [this message]
2021-10-18 12:08         ` Greg KH
2021-10-10 22:22     ` Andi Kleen
2021-10-11 11:59       ` Michael S. Tsirkin
2021-10-11 17:32         ` Andi Kleen
2021-10-11 18:22           ` Michael S. Tsirkin
2021-10-18 12:15         ` Greg KH
2021-10-18 13:17           ` Michael S. Tsirkin
2021-10-11  7:58   ` Christoph Hellwig
2021-10-11 17:23     ` Andi Kleen
2021-10-11 19:09       ` Michael S. Tsirkin
2021-10-12  5:31         ` Christoph Hellwig
2021-10-12 18:37           ` Andi Kleen
2021-10-09  0:37 ` [PATCH v5 13/16] PCI: Mark MSI data shared Kuppuswamy Sathyanarayanan
2021-10-09  0:37 ` [PATCH v5 14/16] virtio: Use shared mappings for virtio PCI devices Kuppuswamy Sathyanarayanan
2021-10-09  0:37 ` [PATCH v5 15/16] x86/tdx: Implement ioremap_host_shared for x86 Kuppuswamy Sathyanarayanan
2021-10-09  0:37 ` [PATCH v5 16/16] x86/tdx: Add cmdline option to force use of ioremap_host_shared Kuppuswamy Sathyanarayanan
2021-10-09  1:45   ` Randy Dunlap
2021-10-09  2:10     ` Kuppuswamy, Sathyanarayanan
2021-10-09 11:04   ` Michael S. Tsirkin
2021-10-11  2:39     ` Andi Kleen
2021-10-11 12:04       ` Michael S. Tsirkin
2021-10-11 17:35         ` Andi Kleen
2021-10-11 18:28           ` Michael S. Tsirkin
2021-10-12 17:55             ` Andi Kleen
2021-10-12 20:59               ` Michael S. Tsirkin
2021-10-12 21:18                 ` Andi Kleen
2021-10-12 21:30                   ` Michael S. Tsirkin
2021-10-15  5:50                     ` Andi Kleen
2021-10-15  6:57                       ` Michael S. Tsirkin
2021-10-15 13:34                         ` Andi Kleen
2021-10-17 22:34                           ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871r4j2l4y.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=bruce.schlobohm@intel.com \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=davem@davemloft.net \
    --cc=david@redhat.com \
    --cc=deller@gmx.de \
    --cc=elena.reshetova@intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=kathleen.kovatch@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=knsathya@kernel.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rth@twiddle.net \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).