From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C99528CF4C for ; Wed, 4 Jun 2025 14:45:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749048337; cv=none; b=LsB1n1/HvCCpKzTdtzJ+A5LI+zBtWawfEgbKQ0bneI2+r+sAM5eldoQKU5A/DEtWtv5mwN/b44OeQrKJbFHO1A2T9eh7vwfXknf7Ib1ZQRPti8SpBV5GP8JPtXwExVQI+vE1gAIaOykKkT3QBr9he0CW86PRKxjPEFUcn/gEEWI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749048337; c=relaxed/simple; bh=hdC0g7jwLGrJCvbTClMyyCacsiNb5NFuarRxRMK7sn0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=h9ajjdgBCj1lua56luFEaRhikTPAA4j28JaxKFvjf5TwXeBVmxwcqBN4PaFeOf9Pa4N+tjirmrmnsYEeVkPEusfz+9qoFNbXS+mL5dg06YB++NYg9lCVs54u9ROQl9jkrTAMkqeV3rH6jGFK5OUCOBoQKvGoCRulioNE5xDdJdo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch; spf=none smtp.mailfrom=ffwll.ch; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b=UEPhZLlt; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ffwll.ch Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="UEPhZLlt" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-3a375e72473so4036847f8f.0 for ; Wed, 04 Jun 2025 07:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; t=1749048334; x=1749653134; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=YVZ9LYN/PFsvpkJ55gMLUB/cURcAGit5abXdVlxI7co=; b=UEPhZLlt/oKFBEqC5kWNwomUkx9CaGxcu08heeA2nMwnRbNDuyMB82zU9INp8XT/k6 AoxyUbYCd7cK95KOiEOqFXCPE4kqc8pNdnISk3wQMpjQhdJpg0UMO21qDKgyT5dwtAHZ yB2btRx1Yl3anr80wIjng+ZmSHH1trBALrebw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749048334; x=1749653134; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YVZ9LYN/PFsvpkJ55gMLUB/cURcAGit5abXdVlxI7co=; b=YXuIIWptiuArWilYtMDFTQD7KMZXlZzCpmiLRR0CAaxV9tlmCK8vOKoBYKw9AzhjCM hPgF3h5XFS7YAFOfKowsMfYMeNR4GA0zHSF7rvzoCnAvxEVEVkywZZ0xb0mugRVan8gc 8mn9pYLwPwLCw84rKU+4+WYoflUqRw2ylMlX1h4y+GI5JF2FM11PKD3R5UyiGNDOrr5b d8eTh2fnv41ucYxYQX796KNGPXgCh8aoS+27wsv4A0OlmQJu3O2OCSVa06gs6U8s6Ja4 wTarXK7ZyRRVHN8TeIcGU5HZO1WjtJtS67gPcwD7ndba1Sibp9Vrf4lViuY2GJrc7EAU TRww== X-Forwarded-Encrypted: i=1; AJvYcCX4/3DKSCDKOo8Dh6G98JSM0+8baBGrqad7Rj+peiz07ndSDI19FiFMzAayevtFLgkiglSFN3m63iF4Iw==@vger.kernel.org X-Gm-Message-State: AOJu0Yw5wP/P/fI0qpysdTAyrXGrgphddA4LukHlG/SJDKZWUFcLKS5b sQs2qLp4U4O4l7y2N5vEFMyazO3O7zgXa6v1fjIUs7LZRcnbQ8GRw6/KrHZxgBHX714= X-Gm-Gg: ASbGncvNKIGEIzxSv5pRTaGSs+OLchFYC29ccU7Xih2M/6em/cBwQOu/yc3reqVN2hp kZ8xAWJ/4WcJPiUoSsoP/56f3rjw5nPrRWXOFNtp038zzCVGAJL2GqoxEEe6clRpAsREgUoqWit MtFd5GfcRBwiLGatokS8IzHBPzK+wMbL/csQlq6yvmf72zIqNFemLA84rz/VeMAYACK8aLmerFA k2khK1VVnvLG/3pklaBoKi7NAlMqGOZWCP4LsUERyog22N9/1Et18Mm+wBkEcY8GiYxaI3SGBvj FdOLiPatuzH6Hu2YVIelBCux34YjjryivldjOZlxLXYKlgXEjufsJ4enWOHXW/Y= X-Google-Smtp-Source: AGHT+IGOzvFV9hOfQGxbhHGh03HLKuvLfdHp1XBpuXusZFIdQzjfviSfpxeGOApY5FswyTJYuDkYTg== X-Received: by 2002:a05:6000:230c:b0:3a4:dcb0:a5f with SMTP id ffacd0b85a97d-3a51dbcd8fdmr2376750f8f.16.1749048333468; Wed, 04 Jun 2025 07:45:33 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:5485:d4b2:c087:b497]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe758besm22135589f8f.51.2025.06.04.07.45.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Jun 2025 07:45:32 -0700 (PDT) Date: Wed, 4 Jun 2025 16:45:30 +0200 From: Simona Vetter To: Thomas Zimmermann Cc: Michael Kelley , David Hildenbrand , "simona@ffwll.ch" , "deller@gmx.de" , "haiyangz@microsoft.com" , "kys@microsoft.com" , "wei.liu@kernel.org" , "decui@microsoft.com" , "akpm@linux-foundation.org" , "weh@microsoft.com" , "hch@lst.de" , "dri-devel@lists.freedesktop.org" , "linux-fbdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers Message-ID: Mail-Followup-To: Thomas Zimmermann , Michael Kelley , David Hildenbrand , "simona@ffwll.ch" , "deller@gmx.de" , "haiyangz@microsoft.com" , "kys@microsoft.com" , "wei.liu@kernel.org" , "decui@microsoft.com" , "akpm@linux-foundation.org" , "weh@microsoft.com" , "hch@lst.de" , "dri-devel@lists.freedesktop.org" , "linux-fbdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-mm@kvack.org" References: <20250523161522.409504-1-mhklinux@outlook.com> <20250523161522.409504-4-mhklinux@outlook.com> <9a93813c-4d7c-45ef-b5a2-0ad37e7a078a@suse.de> Precedence: bulk X-Mailing-List: linux-fbdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9a93813c-4d7c-45ef-b5a2-0ad37e7a078a@suse.de> X-Operating-System: Linux phenom 6.12.25-amd64 On Wed, Jun 04, 2025 at 10:12:45AM +0200, Thomas Zimmermann wrote: > Hi > > Am 03.06.25 um 19:50 schrieb Michael Kelley: > > From: Thomas Zimmermann Sent: Monday, June 2, 2025 11:25 PM > > > Hi > > > > > > Am 03.06.25 um 03:49 schrieb Michael Kelley: > > > [...] > > > > > Will the VMA have VM_PFNMAP or VM_MIXEDMAP set? PFN_SPECIAL is a > > > > > horrible hack. > > > > > > > > > > In another thread, you mention that you use PFN_SPECIAL to bypass the > > > > > check in vm_mixed_ok(), so VM_MIXEDMAP is likely not set? > > > > The VMA has VM_PFNMAP set, not VM_MIXEDMAP. It seemed like > > > > VM_MIXEDMAP is somewhat of a superset of VM_PFNMAP, but maybe that's > > > > a wrong impression. vm_mixed_ok() does a thorough job of validating the > > > > use of __vm_insert_mixed(), and since what I did was allowed, I thought > > > > perhaps it was OK. Your feedback has set me straight, and that's what I > > > > needed. :-) > > > > > > > > But the whole approach is moot with Alistair Popple's patch set that > > > > eliminates pfn_t. Is there an existing mm API that will do mkwrite on a > > > > special PTE in a VM_PFNMAP VMA? I didn't see one, but maybe I missed > > > > it. If there's not one, I'll take a crack at adding it in the next version of my > > > > patch set. > > > What is the motivation behind this work? The driver or fbdev as a whole > > > does not have much of a future anyway. > > > > > > I'd like to suggest removing hyperv_fb entirely in favor of hypervdrm? > > > > > Yes, I think that's the longer term direction. A couple months ago I had an > > email conversation with Saurabh Sengar from the Microsoft Linux team where > > he raised this idea. I think the Microsoft folks will need to drive the deprecation > > process, as they need to coordinate with the distro vendors who publish > > images for running on local Hyper-V and in the Azure cloud. And my > > understanding is that the Linux kernel process would want the driver to > > be available but marked "deprecated" for a year or so before it actually > > goes away. > > We (DRM upstream) recently considered moving some fbdev drivers to > drivers/staging or marking them with !DRM if a DRM driver is available. > Hyverv_fb would be a candidate. > > At least at SUSE, we ship hypervdrm instead of hyperv_fb. This works well on > the various generations of the hyperv system. Much of our userspace would > not be able to use hyperv_fb anyway. Yeah investing into fbdev drivers, especially when some mm surgery seems needed, does not sound like a good idea to me overall. > > I do have some concerns about the maturity of the hyperv_drm driver > > "around the edges". For example, somebody just recently submitted a > > patch to flush output on panic. I have less familiarity hyperv_drm vs. > > hyperv_fb, so some of my concern is probably due to that. We might > > need to do review of hyperv_drm and see if there's anything else to > > deal with before hyperv_fb goes away. > > The panic output is a feature that we recently added to the kernel. It > allows a DRM driver to display a final error message in the case of a kernel > panic (think of blue screens on Windows). Drivers require a minimum of > support to make it work. That's what the hypervdrm patches were about. I'm also happy to help with any other issues and shortfalls of drm vs fbdev. There are some, but I thought it was mostly around some of the low bit color formats that really old devices want, and not anything that hyperv would need. Cheers, Sima > > Best regards > Thomas > > > > > This all got started when I was looking at a problem with hyperv_fb, > > and I found several other related problems, some of which also existed > > in hyperv_drm. You've seen several small'ish fixes from me and Saurabh > > as a result, and this issue with mmap()'ing /dev/fb0 is the last one of that > > set. This fix is definitely a bit bigger, but it's the right fix. On the flip side, > > if we really get on a path to deprecate hyperv_fb, there are hack fixes for > > the mmap problem that are smaller and contained to hyperv_fb. I would > > be OK with a hack fix in that case. > > > > Michael > > -- > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Frankenstrasse 146, 90461 Nuernberg, Germany > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman > HRB 36809 (AG Nuernberg) > -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch