All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v2] virtio_blk: add SECURE ERASE command support
Date: Thu, 22 Sep 2022 12:58:43 -0400	[thread overview]
Message-ID: <20220922125744-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <YyoCXOwRE7NLxTTH@fedora>

On Tue, Sep 20, 2022 at 02:11:40PM -0400, Stefan Hajnoczi wrote:
> On Mon, Sep 19, 2022 at 09:09:05PM +0300, Alvaro Karsz wrote:
> > Thanks for the reply.
> > 
> > > This can be simplified with min_not_zero().
> > 
> > Ok, I will do it in the next version.
> > 
> > > It's worth including a comment here that the discard and secure erase
> > > limits are combined because the Linux block layer only has one limit
> > > value. If the block layer supported independent limit values we wouldn't
> > > need to do this.
> > 
> > Ok.
> > 
> > I'll send a new version once we agree on the max_secure_erase_seg = 0 scenario.
> > Do you have an opinion on that?
> > Do you think that using sg_elems as the number of secure erase/discard
> > segments when the value in the virtio config is 0 is good enough?
> > 
> 
> Okay, I have replied in the max_secure_erase_seg sub-thread. I think
> probing the device should fail if the value is 0. There are no existing
> non-compliant devices that we need to be compatible with - let's
> encourage device implementors to report usable max_secure_erase_seg
> values.
> 
> Stefan

I agree, but do we have to fail probe? Are there security concerns
if secure erase functionality is just disabled in this case?


-- 
MST

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

      parent reply	other threads:[~2022-09-22 16:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-29  8:23 [PATCH v2] virtio_blk: add SECURE ERASE command support Alvaro Karsz
2022-09-01  7:44 ` Alvaro Karsz
2022-09-09  8:33   ` Alvaro Karsz
2022-09-18 13:30 ` Michael S. Tsirkin
2022-09-18 14:01   ` Alvaro Karsz
2022-09-18 15:13     ` Michael S. Tsirkin
2022-09-18 16:07       ` Alvaro Karsz
2022-09-20 18:10         ` Stefan Hajnoczi
2022-09-22 17:00           ` Michael S. Tsirkin
2022-09-19 17:33 ` Stefan Hajnoczi
2022-09-19 18:09   ` Alvaro Karsz
2022-09-20 18:11     ` Stefan Hajnoczi
2022-09-21  6:51       ` Alvaro Karsz
2022-09-22 16:58       ` Michael S. Tsirkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220922125744-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=pbonzini@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.