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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CD3ADF53D69 for ; Mon, 16 Mar 2026 15:43:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:References:Cc:To:From:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OUJsBlIgUApje1fV9jF7YVlGvh9bq+NPczCyWOUxzn0=; b=ItX0hWrWpFE/nNSRVjfWjiLOR3 3vskbYGcCh2+LalIQRXIai1Cs1J7LYefcblJChUZ2mwr7Fh0Usi8OBIJylpaM2mqyGBVC4ePxXT3j QPYx3M3m+wAqJov3Ws+bWDjcw4IGsVAAV0BUN1yK2YMg21vuaZViJFR1FtatwYI4KEwJ6ZcEtk36k qb67I7aK47JBVX64AXf8NdcUb+PYQi1k+UrnUFNzJqIv8wqBC9GoxhtXZhkLWf9wBWqYXUCrsuUag D9xnXNem58wMJbU+Gm/fxvSjV4P45fRhQy4z68cqzKBTebMSfu5T16vKiwYu7a6nH07S34/zBJjl0 hXa5ThAA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1w2A6W-00000004MXH-1lKw; Mon, 16 Mar 2026 15:43:40 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w2A6U-00000004MWV-057r for ath11k@bombadil.infradead.org; Mon, 16 Mar 2026 15:43:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type :In-Reply-To:References:Cc:To:From:Subject:MIME-Version:Date:Message-ID: Sender:Reply-To:Content-ID:Content-Description; bh=OUJsBlIgUApje1fV9jF7YVlGvh9bq+NPczCyWOUxzn0=; b=MbqaLcCsU9/FIjUBlvsl3a1NOw CovvY5o8poyaSr4ql/i6p9juB58jtSEPPzqrL3HhoLSmm8kMxqKwXulW1lJ60aEjchHyB9Qocp9GI VE3R5mTwTUA7WKMFe1KjMMwt9Z5aqtP93aBkSFJ8oREWSpTDKMbqdFkmxN91klGn7ZqFLh9rd6Tz5 qTcCKkrner+mGgXsTZxD0yMGpsrxUFAZWs+mdPWLQYZt+OuMmfJ9/NQdOLMtTMqt8dWFW578x3eZT ZVrGQh0/EgMnGgbGIKQdEh8/kjuasnEJUu/2x2hXGzeIx/3Lty6yFgViswSYIDDVt3lvwItZbrBEF ND5Ntaeg==; Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by desiato.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1w2A6R-000000077Bk-0ZZZ for ath11k@lists.infradead.org; Mon, 16 Mar 2026 15:43:36 +0000 Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-c7384f5a9cdso2027774a12.0 for ; Mon, 16 Mar 2026 08:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773675813; x=1774280613; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=OUJsBlIgUApje1fV9jF7YVlGvh9bq+NPczCyWOUxzn0=; b=h3LyQqYLXXOX697ex3j9C/EyPulZHNdgxILyLG4xCiIG1UJGj8Tmuzk4TWO1lEGksz 5cIm/HQoniVj/VN+svnMhxBNZXdqu3+DEtNfALV9vJMGnV05l9WJXWxL9739jO2WqgSg K0HxMXvksC3Iu1NoNuA+e8/Wj7tHDVIHqhld+V5kvVsXKKQHpENjYBT607+hqczKWJOM nZ7Grs7wsCkd4HUmTfCOQtkiMy3+pSDP+nz7IZ+a3cZacfumzWNlGzXzM39zIskLnqHl MoIfHkmrBO4Kuhq01hKgkkYINVeCZQHDVbDikQ6IuTIqKacydEKrLJ05uq4EoqwMrzYj EjKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773675813; x=1774280613; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=OUJsBlIgUApje1fV9jF7YVlGvh9bq+NPczCyWOUxzn0=; b=sdy2cKtfncCvIBD0mntUMFbk75tu8AskfN2csrzF1Kt4Fu4P3NO6/pw1+QRH1U+BLb bEq17MJraCIRJrh+cTlVzslabG6OngYgOScGRmTaLOVYHnDlVKWL7zJCuODsoUSoH+yl IxgkX7E57zrsaQJ2arN/VK+oIPP9pMaVkoH12Y5y6/fqpC8yqeNNn21PIL1NLJKccMHA 9+dEsc7O9ZGE7X79K1NIquupbIPLbtsRounJwUS41ia/FkJxqRczyOvBBC1ikF+Q989e 05fj271Beu5kovGQ49t/PpxFMt+kNJx6+VLMkFdpzqXwC2v3VbJ1KlDEPORt7WciT7dO 0/Hg== X-Forwarded-Encrypted: i=1; AJvYcCVSzBz3+ckKBPWf3CuQMv8QhnIa58ktfhZPbBGmmvNciqT73IzHTK5e+EoG5sICD0wwWxfTD+A=@lists.infradead.org X-Gm-Message-State: AOJu0Yya0C+kbGwvTT3UX4rGlv7I7SkCHzDPyNUIkJviohCk+Wj7S39B YICyOjY8AKZMjTiJ6ucjXGJP9lJilI8w3O9bd7uZhiliGGaEc6nOeMTo X-Gm-Gg: ATEYQzwDEV8bxk+rG6s3HfiIRvDabZBNOKtTyeQo5+nTmggd/EU/0Jpk4hJ1tjj6Sb0 ZfFkG5cbjHb2KKyDnbBXmy2gf3ih1O00Tm7krgIERj6Q2NKrUyU9wr+ubgVmS+nX3wvu5T0eIJu iDXmS+AOfnl5yM46x2znyUcyrCZ8w0zQVreRkvadu5D2at2KbdgOOGP2OunGhm6duX8np8LeZAr /NcxfCJw1DiFlcW0iBJ2FLba4dbQQL4P97+yO0ACP9aESk3xTfeFemMqypK+a11K9AFIL6X+tep 1eptqT3ea5R8UaARdKTGzzyUZmKnHXE9pwZcBeZvC5GtzrdgSrEHdqucwJ+UA7IvhXPTvR7Bhse rjP4UaVx4NzQHOYXVaa+HA/gcJlV5UWD7HG055+QNTndvAku8BepSFzj9ArXntRRY+R5wvekSCz FvHRVuNLi91hJnPYKE0EqIjDik++sE0CvUePJhmzxoE66cD+JzSo5na76IGJNmK2B0+0/oNWh/x ioHmSDdrskJkVZk7I1hpBxj83Bqbrvg9Vb4 X-Received: by 2002:a05:6a21:2c12:b0:35d:7f7:4aac with SMTP id adf61e73a8af0-398eccf5230mr12827288637.47.1773675812990; Mon, 16 Mar 2026 08:43:32 -0700 (PDT) Received: from [192.168.1.164] (h69-130-12-20.bendor.broadband.dynamic.tds.net. [69.130.12.20]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c73eb996257sm9417128a12.9.2026.03.16.08.43.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Mar 2026 08:43:31 -0700 (PDT) Message-ID: Date: Mon, 16 Mar 2026 08:43:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC/RFT] vfio/pci-quirks: Quirk for ath wireless From: James Prestwood To: Jason Gunthorpe , Alex Williamson Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, quic_bqiang@quicinc.com, kvalo@kernel.org, linux-wireless@vger.kernel.org, ath11k@lists.infradead.org, dwmw2@infradead.org, iommu@lists.linux.dev, kernel@quicinc.com, johannes@sipsolutions.net, jtornosm@redhat.com References: <20240812170045.1584000-1-alex.williamson@redhat.com> <20240813164341.GL1985367@ziepe.ca> <20240813150320.73df43d7.alex.williamson@redhat.com> <20240813233724.GS1985367@ziepe.ca> <20240815105905.19d69576.alex.williamson@redhat.com> <20240815171935.GO3468552@ziepe.ca> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260316_154335_186657_1BA054CF X-CRM114-Status: GOOD ( 29.33 ) X-BeenThere: ath11k@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "ath11k" Errors-To: ath11k-bounces+ath11k=archiver.kernel.org@lists.infradead.org On 3/16/26 7:58 AM, James Prestwood wrote: > On 8/15/24 10:19 AM, Jason Gunthorpe wrote: >> On Thu, Aug 15, 2024 at 10:59:05AM -0600, Alex Williamson wrote: >> >>>> This is probably the only way to approach this, trap and emulate the >>>> places in the device that program additional interrupt sources and do >>>> a full MSI-like flow to set them up in the kernel. >>> Your last sentence here seems to agree with this approach, but >>> everything else suggests disapproval, so I don't know where you're >>> going here. >> Trapping and emulating is fine. >> >> My concern is really only about skipping SET_IRQ. >> >> That works because of the assumption that the IMS sources are going to >> re-use addr/data pairs setup in the MSI CAP. >> >> That assumption is frail, and won't work at all under the proper IMS >> support Linux now has. >> >> I really don't want to go down the road and have someone tell Thomas >> he can't convert the Linux driver to use irq_domain IMS because it >> will break this stuff here. >> >>> I have no specs for this device, nor any involvement from the device >>> vendor, so the idea of creating a vfio-pci variant driver to setup an >>> irq_domain and augment a device specific SET_IRQs ioctls not only >>> sounds >>> tremendously more complicated (host and VMM), it's simply not possible >>> with the knowledge we have at hand. >> It seems like you have reverse engineered alot of the necessary >> information though?? >> >> Maybe there is a more generic approach than a variant driver. If you >> wanted to use IMS from userspace generically you could imagine some >> kind of IMS focused "SET_IRQ" in generic VFIO. Where we'd create the >> needed irq_domains and pass the addr/data pair back to userspace? >> >>> I observe that the device configures MSI vectors and then writes that >>> same vector address/data elsewhere into the device.  Whether the device >>> can trigger those vectors based only on the MSI capability programming >>> and a secondary source piggybacks on those vectors or if this is just a >>> hack by Qualcomm to use an MSI capability to acquire some vectors which >>> are exclusively used by the secondary hardware, I have no idea. >> Well at least that should be testable - but it seems crazy if the >> device has registers for an addr/data pair and then somehow doesn't >> use the values that get put in them?? >> >> Copying from the MSI is almost certainly a SW hack because IMS support >> has never really existed in an OS until now. I think your guess for >> why it is like this is pretty good. >> >>> I do not believe that introducing a vfio device feature that disables >>> virtualization of the MSI address/data _only_ at the vfio interface >>> (not to a QEMU VM) provides some implicit support of this device >>> behavior.  These values are already available to a privileged user in >>> the host and the same is available for an MSI-X use case by directly >>> reading the MSI-X vector table. >> To be clear, I'm not really worried about showing the data to >> userspace. >> >> Userspace just shouldn't be using it to implement an IMS technique! >> >> Jason > > I see this thread went stale. Wondering if there was ever a final > conclusion if this could get fixed for ath11k or not. I tried again on > a recent kernel, 6.17, and see the same behavior. > > Thanks, > > James > I addition, I've looked at various kernel version and see no time where there was ever a "hw/vfio/pci-quirks.c" file in the tree. I tried many versions between 6.17 and 5.11, I don't see the "hw" directory at all. I'd like to try this patch out, but might need some guidance on what kernel version this was meant for and if files may have shuffled around. Thanks, James