From: Marc Orr <firstname.lastname@example.org>
To: Mingwei Zhang <email@example.com>
Cc: Brijesh Singh <firstname.lastname@example.org>,
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>,
Peter Gonda <firstname.lastname@example.org>,
Vipin Sharma <email@example.com>
Subject: Re: [PATCH v2 3/4] KVM: SVM: move sev_bind_asid to psp
Date: Thu, 9 Sep 2021 18:23:29 -0700 [thread overview]
Message-ID: <CAA03e5HK1Qkk0uyZRi_ncFewJ5yStXWGT7REQdYQ2Z1BYHcCew@mail.gmail.com> (raw)
On Thu, Sep 9, 2021 at 6:18 PM Mingwei Zhang <firstname.lastname@example.org> wrote:
> > 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.
> > thanks
> 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.
Isn't the first patch in this patch set a straight-forward bug fix
:-)? Assuming others agree, I'd suggest to re-send that one out as a
single patch on its own, so we can get it merged while the rest of
this patch set works its way through the process.
next prev parent reply other threads:[~2021-09-10 1:24 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
2021-09-10 1:23 ` Marc Orr [this message]
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).