From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D681DC433E3 for ; Fri, 21 Aug 2020 19:47:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B5FC120FC3 for ; Fri, 21 Aug 2020 19:47:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="KiXQi33X"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="ZNTKZwPc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726243AbgHUTrs (ORCPT ); Fri, 21 Aug 2020 15:47:48 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:58382 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726440AbgHUTrr (ORCPT ); Fri, 21 Aug 2020 15:47:47 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1598039264; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oc6rWuK4RWluEJBMD17wpMBfxGYcOFdDWSkk5lcadvw=; b=KiXQi33Xg/nd2cc5p/iAKtPJMeJNOzlCIzhWjWEbDdZsQcUjTDcZub6BshDwVTeuzhZGv3 zw2QKFIaV6T0xnr0tMl0umwZIX8sVQuHMEUfRQUVCSNH+RS3Ctu3yRElL1RDrH9OSkUBvR Tsr3wMNO6B9xByzMz6gnGKvZsy58iZhaXxtRYkjnJJ3WTiyQxefyan9gZqT9mGBT6u+xX7 879KRDH1ZIZQf7iaP+awji6DDAUxA8bYq12w27+m5dPt9dX2xBuAi7ENRI59fAae7fEgGi t8GgtNuJOLOuihUaToMYiDcn5kSYsxXPj3V4PLzYavwP+TAnb34LXNCN2fVjfQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1598039264; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oc6rWuK4RWluEJBMD17wpMBfxGYcOFdDWSkk5lcadvw=; b=ZNTKZwPc7JAJl8Qd563jtK8cr0w4Fu55mv5EH+kVE+8/1HT5hcM/atj4LWnPcJrRJGhXkM niAVH0dbiv4S6wAA== To: Jason Gunthorpe Cc: LKML , x86@kernel.org, Marc Zyngier , Megha Dey , Dave Jiang , Alex Williamson , Jacob Pan , Baolu Lu , Kevin Tian , Dan Williams , Joerg Roedel , iommu@lists.linux-foundation.org, linux-hyperv@vger.kernel.org, Haiyang Zhang , Jon Derrick , Lu Baolu , Wei Liu , "K. Y. Srinivasan" , Stephen Hemminger , Steve Wahl , Dimitri Sivanich , Russ Anderson , linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Konrad Rzeszutek Wilk , xen-devel@lists.xenproject.org, Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Greg Kroah-Hartman , "Rafael J. Wysocki" Subject: Re: [patch RFC 38/38] irqchip: Add IMS array driver - NOT FOR MERGING In-Reply-To: <20200821124547.GY1152540@nvidia.com> References: <20200821002424.119492231@linutronix.de> <20200821002949.049867339@linutronix.de> <20200821124547.GY1152540@nvidia.com> Date: Fri, 21 Aug 2020 21:47:43 +0200 Message-ID: <874kovsrvk.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-hyperv-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Fri, Aug 21 2020 at 09:45, Jason Gunthorpe wrote: > On Fri, Aug 21, 2020 at 02:25:02AM +0200, Thomas Gleixner wrote: >> +static void ims_mask_irq(struct irq_data *data) >> +{ >> + struct msi_desc *desc = irq_data_get_msi_desc(data); >> + struct ims_array_slot __iomem *slot = desc->device_msi.priv_iomem; >> + u32 __iomem *ctrl = &slot->ctrl; >> + >> + iowrite32(ioread32(ctrl) & ~IMS_VECTOR_CTRL_UNMASK, ctrl); > > Just to be clear, this is exactly the sort of operation we can't do > with non-MSI interrupts. For a real PCI device to execute this it > would have to keep the data on die. We means NVIDIA and your new device, right? So if I understand correctly then the queue memory where the MSI descriptor sits is in RAM. How is that supposed to work if interrupt remapping is disabled? That means irq migration and proper disabling of an interrupt become an interesting exercise. I'm so not looking forward to that. If interrupt remapping is enabled then both are trivial because then the irq chip can delegate everything to the parent chip, i.e. the remapping unit. Can you please explain that a bit more precise? > I saw the idxd driver was doing something like this, I assume it > avoids trouble because it is a fake PCI device integrated with the > CPU, not on a real PCI bus? That's how it is implemented as far as I understood the patches. It's device memory therefore iowrite32(). > It is really nice to see irq_domain used properly in x86! If you ignore the abuse in XEN :) And to be fair proper and usable (hierarchical) irq domains originate from x86 and happened to solve quite a few horrorshows on the ARM side. Just back then when we converted the original maze, nobody had a good idea and the stomach to touch XEN. Thanks, tglx