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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA349C433F5 for ; Wed, 17 Nov 2021 06:15:42 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 84AB761B2B for ; Wed, 17 Nov 2021 06:15:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 84AB761B2B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:44150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mnEEK-0006hK-4z for qemu-devel@archiver.kernel.org; Wed, 17 Nov 2021 01:15:38 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnDtI-0003uh-Sg; Wed, 17 Nov 2021 00:53:52 -0500 Received: from bombadil.infradead.org ([198.137.202.133]:57268) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnDtF-0004gt-Sj; Wed, 17 Nov 2021 00:53:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UZIGL4rir57xpB6m+PG7mTxDJ1KUVpUcHZBCLH0PHdo=; b=e2hLuBq6+Henvq1h68mQi2RirC breympNBuViWhFI8zWWYEFkT7RVgELpRyil7x66qDwmIiNV2MWAdWBqu6w4/+1zDz5XKDxf7CP4zC G3OExAZdmExmfUsbeZQ9nF/PnyR6w78nkHUm1IrEsMusNUq8ygeUDDBu5It3FfMHONAP5DPRdznHU 1ahXi+p6h2trapqAulhr7kf8++xVRTa4CvR56U74ES3LW8Kfody02XqzTENHZCjjdViwzKOddv7eC Pg737D5IxodBKnLUMCTjiIVNsTJgh8U9uvKL+Usb/GSoFU+fWjJnny9I8Rl1AWqJ0r+ntuiPbOQoo Y8crQm4g==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mnDt5-003OVl-1w; Wed, 17 Nov 2021 05:53:39 +0000 Date: Tue, 16 Nov 2021 21:53:39 -0800 From: Christoph Hellwig To: Stefan Hajnoczi Subject: Re: [PATCH 1/2] block:hdev: support BLKSECDISCARD Message-ID: References: <20211115045200.3567293-1-yadong.qi@intel.com> <20211115045200.3567293-2-yadong.qi@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Received-SPF: none client-ip=198.137.202.133; envelope-from=BATV+f4c01cfe20b1e1ad945a+6660+infradead.org+hch@bombadil.srs.infradead.org; helo=bombadil.infradead.org X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Axboe , "kwolf@redhat.com" , "qemu-block@nongnu.org" , "mst@redhat.com" , "Chen, Luhai" , "qemu-devel@nongnu.org" , Christoph Hellwig , "Wang, Kai Z" , "hreitz@redhat.com" , "fam@euphon.net" , "Qi, Yadong" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, Nov 16, 2021 at 10:58:30AM +0000, Stefan Hajnoczi wrote: > Question for Jens and Christoph: > > Is there a way for userspace to detect whether a Linux block device > supports SECDISCARD? I don't know of one. > If not, then maybe a new sysfs attribute can be added: This looks correct, but if we start looking into SECDISCARD seriously I'd like to split the max_sectors settings for it from discard as that is currently a bit of a mess. If we then expose the secure erase max sectors in sysfs that would also be a good indicator. What is the use case for exposing secure erase in qemu? The whole concept for a LBA based secure erase is generally not a very smart idea for flash based media..