From: Mingwei Zhang <email@example.com>
To: Brijesh Singh <firstname.lastname@example.org>
Cc: Sean Christopherson <email@example.com>,
Paolo Bonzini <firstname.lastname@example.org>,
Tom Lendacky <email@example.com>,
John Allen <firstname.lastname@example.org>,
Vitaly Kuznetsov <email@example.com>,
Wanpeng Li <firstname.lastname@example.org>,
Jim Mattson <email@example.com>, Joerg Roedel <firstname.lastname@example.org>,
email@example.com, LKML <firstname.lastname@example.org>,
Alper Gun <email@example.com>, Borislav Petkov <firstname.lastname@example.org>,
David Rienjes <email@example.com>,
Marc Orr <firstname.lastname@example.org>, Peter Gonda <email@example.com>,
Vipin Sharma <firstname.lastname@example.org>
Subject: Re: [PATCH v2 3/4] KVM: SVM: move sev_bind_asid to psp
Date: Thu, 9 Sep 2021 18:18:00 -0700 [thread overview]
Message-ID: <CAL715WL6g3P6QKv1w-zSDvY3jjLVdbfxaqyr2XV_NicnuP2+EQ@mail.gmail.com> (raw)
> I believe once we are done with it, will have 5 functions that will need
> >=8 arguments. I don't know if its acceptable.
> > In addition, having to construct each sev_data_* structure in KVM code
> > is also a pain and consumes a lot of irrelevant lines as well.
> Maybe I am missing something, aren't those lines will be moved from KVM
> to PSP driver?
> I am in full support for restructuring, but lets look at full set of PSP
> APIs before making the final decision.
Oh, sorry for the confusion. I think the current feedback I got is
that my restructuring patchset was blocked due to the fact that it is
a partial one. So, if this patchset got checked in, then the psp-sev.h
will have two types of APIs: ones that use sev_data_* structure and
ones that do not. So one of the worries is that this would make the
situation even worse.
So that's why I am thinking that maybe it is fine to just avoid using
sev_data_* for all PSP functions exposed to KVM? I use the number of
arguments as the justification. But that might not be a good one.
In anycase, I will not rush into any code change before we reach a consensus.
next prev parent reply other threads:[~2021-09-10 1:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 5:39 [PATCH v2 0/4] clean up interface between KVM and psp Mingwei Zhang
2021-08-18 5:39 ` [PATCH v2 1/4] KVM: SVM: fix missing sev_decommission in sev_receive_start Mingwei Zhang
2021-08-21 2:11 ` Marc Orr
2021-08-21 2:30 ` Marc Orr
2021-08-18 5:39 ` [PATCH v2 2/4] KVM: SVM: move sev_decommission to psp driver Mingwei Zhang
2021-08-18 5:39 ` [PATCH v2 3/4] KVM: SVM: move sev_bind_asid to psp Mingwei Zhang
2021-09-03 19:38 ` Sean Christopherson
2021-09-07 16:30 ` Brijesh Singh
2021-09-07 23:37 ` Sean Christopherson
2021-09-09 16:07 ` Brijesh Singh
2021-09-09 18:13 ` Sean Christopherson
2021-09-09 21:18 ` Mingwei Zhang
2021-09-09 22:25 ` Brijesh Singh
2021-09-10 1:18 ` Mingwei Zhang [this message]
2021-09-10 1:23 ` Marc Orr
2021-08-18 5:39 ` [PATCH v2 4/4] KVM: SVM: move sev_unbind_asid and DF_FLUSH logic into psp Mingwei Zhang
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).