From nobody Thu Aug 29 12:13:32 2024 X-Original-To: wireless@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WvgDM3VNqz5Mrld for ; Thu, 29 Aug 2024 12:13:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WvgDM2wM3z4XPV for ; Thu, 29 Aug 2024 12:13:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724933619; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=9zxNhko6Pg2Rum8xmcEoSobTAgN14BDYUYAX7tXqNew=; b=IUb6aBzoVGSLAltKAGY42ABafPnqFzwzWmMwYscJAWNwz7EUswPvqejGWzye88npP+A8vq GwSD5B2zeuYWaw1crpY++jrJPptVj3jerBUb6MRPzdPzl0OR0lbLBG2Bo1+E7p4oZseEXa aiS1w0PGL4XilhhiMCxXQGmk+yeh15umhdVwHLA0WBlEPCT6Oun5Uew+aPMu9Nx7Ti3Yk/ DE7RllmkxVh4VvREhBfH8I4x8R3Gb+xUZ0SJ9T8FL9N4DHoprnTnYjCVHKBkqTIpLHxcR7 xBTTlsNW8hej4f/yG4Izm0tXvbcNxLIEfkDTzxDvJ1bmf0LluwgYh89iPjrDgw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1724933619; a=rsa-sha256; cv=none; b=a8+Be2sKrgexX4eagAWTK+3ci9jVUXxCSl89bFCmQ6PCplMD2fRoFXArMRmxU24voInTEe k5RIDOZfofV5/DQ5iSTkrgWQYyOU7sP37Uxrg/b6n93ydplKaWnL7WuDY7qMFoWTeDOPwr Cw+cI91lj2ujS4yqBbGFj0e1Km9+a15JbbS/lE1VG0+8WEn0fmjppJ0n9vbihOUVjJn68l tAz/Ji8tlK4o+ldeM/6lCC6jvKc1N2qnkq3F4tA9MzcxbiZ0Q+5Wlb7sdmn9ZlFoC2xL4w 2dkR4tQ/gpboK8R6xpgK5FI9K6PjSIyx85jz5GqmNhk0I2s3qBr077bS+NXsNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724933619; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=9zxNhko6Pg2Rum8xmcEoSobTAgN14BDYUYAX7tXqNew=; b=VALooOooktCosvxxY5PmaHcVRCR3Jh0WAsOgtwoBNs4imwWtSZk6MTKm8KU/YB9uko/fYB 1JbUb7WL6hBNz2KRDX2DFY+34jlCqavD89ntSg7bSy2w8QF1CYZT3dYZxh4tj7AGxxocQn E0bOR3zqDbOHSKU9w2KN7wNsnkoLVJ3rZl1QMSh/ZDWUzXPAUBy/LnmaU4MDGocoHFPoOK X3C3GkKvCibVckgTaHsDr7xZQg8U0zmG4IOOf1Zx5uMYVcvGUkE94XRcmavnvR2E4V7Yw5 f8v1lI3htmH3PJ0BiRdcGyBFXMHTN0asqNa8ap4ybUAK6lNpnuAOZXbnhkSk4g== Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx-01.divo.sbone.de", Issuer "E5" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4WvgDM1ZfGzJb1 for ; Thu, 29 Aug 2024 12:13:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id A8C8BA64806 for ; Thu, 29 Aug 2024 12:13:34 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1D7A52D029D8 for ; Thu, 29 Aug 2024 12:13:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id ErQCbk9-mA2B for ; Thu, 29 Aug 2024 12:13:36 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id DC63A2D029D2 for ; Thu, 29 Aug 2024 12:13:35 +0000 (UTC) Date: Thu, 29 Aug 2024 12:13:32 +0000 (UTC) From: "Bjoern A. Zeeb" To: FreeBSD wireless mailing list Subject: The blocker on MediaTek mt76 drivers - VM changes in LinuxKPI Message-ID: <3pr128oo-q8ro-8o9s-3547-8sq636pnon23@SerrOFQ.bet> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-wireless@freebsd.org Sender: owner-freebsd-wireless@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Hi, a lot of people are asking for the mt76 drivers it seems. They are sitting there and on my branch are compiling (if one flips a switch) but are NOT IN A WORKING STATE YET. In order to make progress a feature called page_pools needs implementation as pi@ has already pointed out on the PR [1]. Before that can happen a 10-15 year old very good but historic shortcut in LinuxKPI needs to be resolved. So far the LinuxKPI 'struct page' is defined to the native 'struct vm_page'. We cannot extend the native struct vm_page with LinuxKPI specific fields. It would both sooner or later become complicated but also penalize the native system massively. But more things (like page_pools) need direct access to fields inside struct page, so it's time to break that historic bit up and enhance our implementation. In my github branch was a start to change that by changing most consumers and macros (some already in main; some that were added since need adjustment) inside LinuxKPI to use a "struct page { }" which no longer ist the native vm_gae. I put an #ifdef PAGE_IS_LKPI_PAGE around that so we can flip from one implementation to the other. I know drm-kmod has at least one workaround in its code for a similar problem that functions want direct access to struct page fields. And drm-kmod will also need to be tested very carefully with the chnage before we do the switch. So what needs doing? To my memory and from a comment in my linux_page.c on github the native page table can be built in at least three ways depending on PMAP_HAS_PAGE_ARRAY and VM_PHYSSEG_SPARSE or VM_PHYSSEG_DENSE. The "shadow copy" of vm_page_array[] which we need in LinuxKPI for struct page needs to be replicated/setup correctly in all cases so that we can do a 1:1 mapping between native pages and LinuxKPI struct page. In the Linux->native direction we could store a pointer to the vm_page for that but in the other direction we need to be able to find the struct page based on the vm_page idx (at least that's what my memory tells me and I am not an expert in that field). This is something which I didn't want to dig deeper into the VM code; I know that a first blunt attempt hadn't work so I figured someone who knows the system can probably do this in a way shorter time and do it right so it can be maintained in the future. I am still looking for someone who can help doing this. [side note: one could argue to change the driver(s) and write these bits as native code but it'll likely end up in a maintainance mess given the amount of churn happening there] Once that logic is there to set this all up, make sure it satisfies all logic to stay in proper synch and that we can (in theory) also properly clean it up, then the next steps folllow, which oversimplified are: 1. Implement page_pools and other missing bits for mt76 in LinuxKPI (some probably as we go) 2. Start testing and debugging the various mt76 driver(s) to load (symbols, module dependencies, ...) 3. Get it to load firmware and register the WiFi interface 4. Take it from there... For any of these steps I'll be more than happy if other people will do them or help; I have some cards for at least two of the chipsets to test and help myself as needed. I hope this clarifies the situation. Lots of health, Bjoern [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264300#c23 -- Bjoern A. Zeeb r15:7