v2 -> v3:
  Rename virtio_crypto_algs.c to virtio_crypto_skcipher_algs.c, and
    minor changes of function name.
  Minor changes in virtio_crypto_akcipher_algs.c: no need to copy from
    buffer if opcode is verify.

v1 -> v2:
  Fix 1 compiling warning reported by kernel test robot <lkp@intel.com>
  Put "__le32 akcipher_algo;" instead of "__le32 reserve;" field of
    struct virtio_crypto_config directly without size change.
  Add padding in struct virtio_crypto_ecdsa_session_para to keep
    64-bit alignment.
  Remove irrelevant change by code format alignment.

  Also CC crypto gurus Herbert and linux-crypto@vger.kernel.org.

  Test with QEMU(patched by the v2 version), works fine.

v1:
  Introduce akcipher service, implement RSA algorithm, and a minor fix.

zhenwei pi (4):
  virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC
  virtio-crypto: introduce akcipher service
  virtio-crypto: implement RSA algorithm
  virtio-crypto: rename skcipher algs

 drivers/crypto/virtio/Makefile                |   3 +-
 .../virtio/virtio_crypto_akcipher_algs.c      | 585 ++++++++++++++++++
 drivers/crypto/virtio/virtio_crypto_common.h  |   7 +-
 drivers/crypto/virtio/virtio_crypto_core.c    |   6 +-
 drivers/crypto/virtio/virtio_crypto_mgr.c     |  15 +-
 ...o_algs.c => virtio_crypto_skcipher_algs.c} |   4 +-
 include/uapi/linux/virtio_crypto.h            |  82 ++-
 7 files changed, 693 insertions(+), 9 deletions(-)
 create mode 100644 drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
 rename drivers/crypto/virtio/{virtio_crypto_algs.c => virtio_crypto_skcipher_algs.c} (99%)

-- 
2.20.1

Hi, Michael & Lei

The full patchset has been reviewed by Gonglei, thanks to Gonglei.
Should I modify the virtio crypto specification(use "__le32 
akcipher_algo;" instead of "__le32 reserve;" only, see v1->v2 change), 
and start a new issue for a revoting procedure?

Also cc Cornelia Huck.

On 3/2/22 11:39 AM, zhenwei pi wrote:
> v2 -> v3:
>    Rename virtio_crypto_algs.c to virtio_crypto_skcipher_algs.c, and
>      minor changes of function name.
>    Minor changes in virtio_crypto_akcipher_algs.c: no need to copy from
>      buffer if opcode is verify.
> 
> v1 -> v2:
>    Fix 1 compiling warning reported by kernel test robot <lkp@intel.com>
>    Put "__le32 akcipher_algo;" instead of "__le32 reserve;" field of
>      struct virtio_crypto_config directly without size change.
>    Add padding in struct virtio_crypto_ecdsa_session_para to keep
>      64-bit alignment.
>    Remove irrelevant change by code format alignment.
> 
>    Also CC crypto gurus Herbert and linux-crypto@vger.kernel.org.
> 
>    Test with QEMU(patched by the v2 version), works fine.
> 
> v1:
>    Introduce akcipher service, implement RSA algorithm, and a minor fix.
> 
> zhenwei pi (4):
>    virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC
>    virtio-crypto: introduce akcipher service
>    virtio-crypto: implement RSA algorithm
>    virtio-crypto: rename skcipher algs
> 
>   drivers/crypto/virtio/Makefile                |   3 +-
>   .../virtio/virtio_crypto_akcipher_algs.c      | 585 ++++++++++++++++++
>   drivers/crypto/virtio/virtio_crypto_common.h  |   7 +-
>   drivers/crypto/virtio/virtio_crypto_core.c    |   6 +-
>   drivers/crypto/virtio/virtio_crypto_mgr.c     |  15 +-
>   ...o_algs.c => virtio_crypto_skcipher_algs.c} |   4 +-
>   include/uapi/linux/virtio_crypto.h            |  82 ++-
>   7 files changed, 693 insertions(+), 9 deletions(-)
>   create mode 100644 drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
>   rename drivers/crypto/virtio/{virtio_crypto_algs.c => virtio_crypto_skcipher_algs.c} (99%)
> 

-- 
zhenwei pi

On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote:
> Hi, Michael & Lei
> 
> The full patchset has been reviewed by Gonglei, thanks to Gonglei.
> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;"
> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue
> for a revoting procedure?

You can but not it probably will be deferred to 1.3. OK with you?

> Also cc Cornelia Huck.
> 
> On 3/2/22 11:39 AM, zhenwei pi wrote:
> > v2 -> v3:
> >    Rename virtio_crypto_algs.c to virtio_crypto_skcipher_algs.c, and
> >      minor changes of function name.
> >    Minor changes in virtio_crypto_akcipher_algs.c: no need to copy from
> >      buffer if opcode is verify.
> > 
> > v1 -> v2:
> >    Fix 1 compiling warning reported by kernel test robot <lkp@intel.com>
> >    Put "__le32 akcipher_algo;" instead of "__le32 reserve;" field of
> >      struct virtio_crypto_config directly without size change.
> >    Add padding in struct virtio_crypto_ecdsa_session_para to keep
> >      64-bit alignment.
> >    Remove irrelevant change by code format alignment.
> > 
> >    Also CC crypto gurus Herbert and linux-crypto@vger.kernel.org.
> > 
> >    Test with QEMU(patched by the v2 version), works fine.
> > 
> > v1:
> >    Introduce akcipher service, implement RSA algorithm, and a minor fix.
> > 
> > zhenwei pi (4):
> >    virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC
> >    virtio-crypto: introduce akcipher service
> >    virtio-crypto: implement RSA algorithm
> >    virtio-crypto: rename skcipher algs
> > 
> >   drivers/crypto/virtio/Makefile                |   3 +-
> >   .../virtio/virtio_crypto_akcipher_algs.c      | 585 ++++++++++++++++++
> >   drivers/crypto/virtio/virtio_crypto_common.h  |   7 +-
> >   drivers/crypto/virtio/virtio_crypto_core.c    |   6 +-
> >   drivers/crypto/virtio/virtio_crypto_mgr.c     |  15 +-
> >   ...o_algs.c => virtio_crypto_skcipher_algs.c} |   4 +-
> >   include/uapi/linux/virtio_crypto.h            |  82 ++-
> >   7 files changed, 693 insertions(+), 9 deletions(-)
> >   create mode 100644 drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
> >   rename drivers/crypto/virtio/{virtio_crypto_algs.c => virtio_crypto_skcipher_algs.c} (99%)
> > 
> 
> -- 
> zhenwei pi

On 3/7/22 5:05 PM, Michael S. Tsirkin wrote:
> On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote:
>> Hi, Michael & Lei
>>
>> The full patchset has been reviewed by Gonglei, thanks to Gonglei.
>> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;"
>> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue
>> for a revoting procedure?
> 
> You can but not it probably will be deferred to 1.3. OK with you?
> 

OK!

-- 
zhenwei pi

On Mon, Mar 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote:
>> Hi, Michael & Lei
>> 
>> The full patchset has been reviewed by Gonglei, thanks to Gonglei.
>> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;"
>> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue
>> for a revoting procedure?
>
> You can but not it probably will be deferred to 1.3. OK with you?
>
>> Also cc Cornelia Huck.

[Apologies, I'm horribly behind on my email backlog, and on virtio
things in general :(]

The akcipher update had been deferred for 1.2, so I think it will be 1.3
material. However, I just noticed while browsing the fine lwn.net merge
window summary that this seems to have been merged already. That
situation is less than ideal, although I don't expect any really bad
problems, given that there had not been any negative feedback for the
spec proposal that I remember.

On Mon, Apr 04, 2022 at 05:39:24PM +0200, Cornelia Huck wrote:
> On Mon, Mar 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote:
> >> Hi, Michael & Lei
> >> 
> >> The full patchset has been reviewed by Gonglei, thanks to Gonglei.
> >> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;"
> >> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue
> >> for a revoting procedure?
> >
> > You can but not it probably will be deferred to 1.3. OK with you?
> >
> >> Also cc Cornelia Huck.
> 
> [Apologies, I'm horribly behind on my email backlog, and on virtio
> things in general :(]
> 
> The akcipher update had been deferred for 1.2, so I think it will be 1.3
> material. However, I just noticed while browsing the fine lwn.net merge
> window summary that this seems to have been merged already. That
> situation is less than ideal, although I don't expect any really bad
> problems, given that there had not been any negative feedback for the
> spec proposal that I remember.

Let's open a 1.3 branch? What do you think?

-- 
MST

On Tue, Apr 05 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Mon, Apr 04, 2022 at 05:39:24PM +0200, Cornelia Huck wrote:
>> On Mon, Mar 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> 
>> > On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote:
>> >> Hi, Michael & Lei
>> >> 
>> >> The full patchset has been reviewed by Gonglei, thanks to Gonglei.
>> >> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;"
>> >> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue
>> >> for a revoting procedure?
>> >
>> > You can but not it probably will be deferred to 1.3. OK with you?
>> >
>> >> Also cc Cornelia Huck.
>> 
>> [Apologies, I'm horribly behind on my email backlog, and on virtio
>> things in general :(]
>> 
>> The akcipher update had been deferred for 1.2, so I think it will be 1.3
>> material. However, I just noticed while browsing the fine lwn.net merge
>> window summary that this seems to have been merged already. That
>> situation is less than ideal, although I don't expect any really bad
>> problems, given that there had not been any negative feedback for the
>> spec proposal that I remember.
>
> Let's open a 1.3 branch? What do you think?

Yes, that's probably best, before things start piling up.

On Tue, Apr 05, 2022 at 10:33:42AM +0200, Cornelia Huck wrote:
> On Tue, Apr 05 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Mon, Apr 04, 2022 at 05:39:24PM +0200, Cornelia Huck wrote:
> >> On Mon, Mar 07 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> 
> >> > On Mon, Mar 07, 2022 at 10:42:30AM +0800, zhenwei pi wrote:
> >> >> Hi, Michael & Lei
> >> >> 
> >> >> The full patchset has been reviewed by Gonglei, thanks to Gonglei.
> >> >> Should I modify the virtio crypto specification(use "__le32 akcipher_algo;"
> >> >> instead of "__le32 reserve;" only, see v1->v2 change), and start a new issue
> >> >> for a revoting procedure?
> >> >
> >> > You can but not it probably will be deferred to 1.3. OK with you?
> >> >
> >> >> Also cc Cornelia Huck.
> >> 
> >> [Apologies, I'm horribly behind on my email backlog, and on virtio
> >> things in general :(]
> >> 
> >> The akcipher update had been deferred for 1.2, so I think it will be 1.3
> >> material. However, I just noticed while browsing the fine lwn.net merge
> >> window summary that this seems to have been merged already. That
> >> situation is less than ideal, although I don't expect any really bad
> >> problems, given that there had not been any negative feedback for the
> >> spec proposal that I remember.
> >
> > Let's open a 1.3 branch? What do you think?
> 
> Yes, that's probably best, before things start piling up.

OK, want to do it? And we can then start voting on 1.3 things
straight away.

-- 
MST