From: Borislav Petkov <bp@alien8.de>
To: Dionna Glaze <dionnaglaze@google.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Tom Lendacky <Thomas.Lendacky@amd.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Joerg Roedel <jroedel@suse.de>, Peter Gonda <pgonda@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Venu Busireddy <venu.busireddy@oracle.com>,
Michael Roth <michael.roth@amd.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Michael Sterritt <sterritt@google.com>
Subject: Re: [PATCH v13 1/4] virt/coco/sev-guest: Add throttling awareness
Date: Mon, 30 Jan 2023 12:13:26 +0100 [thread overview]
Message-ID: <Y9emVjoTBrM2+Y5P@zn.tnic> (raw)
In-Reply-To: <20230124211455.2563674-2-dionnaglaze@google.com>
On Tue, Jan 24, 2023 at 09:14:52PM +0000, Dionna Glaze wrote:
> The host is permitted and encouraged to throttle guest requests to the
> AMD-SP since it is a shared resource across all VMs. Without
> throttling-awareness, the host returning an error will immediately lock
> out access to the VMPCK, which makes the VM less useful as it can't
> attest itself. Since throttling is expected to be a common occurrence, a
> cooperative host can return a VMM error code that the request was
> throttled.
So where is this concept of guest throttling documented?
It sounds like this is something hypervisors do and it is all fine and
great to do that but where does it say: yes, this is what we do and this
is the usual behavior that's expected from guests and HVs to adhere to
when accessing this shared resource?
Tom, is that in the spec somewhere perhaps? Or was this decided upon on
some call?
In any case, I'd like for us to document it somewhere eventually if that
hasn't happened yet so that all parties are clear on what is supposed to
happen and what the protocol is.
> +retry:
> /*
> * Call firmware to process the request. In this function the encrypted
> * message enters shared memory with the host. So after this call the
> @@ -346,6 +347,14 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
> */
> rc = snp_issue_guest_request(exit_code, &snp_dev->input, &err);
>
> + /*
> + * The host may return SNP_GUEST_REQ_ERR_EBUSY if the request has been
> + * throttled. Retry in the driver to avoid returning and reusing the
> + * message sequence number on a different message.
> + */
> + if (err == SNP_GUEST_REQ_ERR_BUSY)
> + goto retry;
I don't like even potential endless loops.
How about you turn this into a loop with a sufficiently large retry
count which, when depleted, gets this request failed with a -ETIMEDOUT
or what not?
You could also stick a cond_resched() in that loop so that it can take a
breather between the requests and doesn't hammer the hw as much.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2023-01-30 11:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 21:14 [PATCH v13 0/4] Add throttling detection to sev-guest Dionna Glaze
2023-01-24 21:14 ` [PATCH v13 1/4] virt/coco/sev-guest: Add throttling awareness Dionna Glaze
2023-01-25 17:28 ` Tom Lendacky
2023-01-25 17:48 ` Dionna Amalie Glaze
2023-01-25 18:31 ` Tom Lendacky
2023-01-30 11:13 ` Borislav Petkov [this message]
2023-01-30 16:36 ` Tom Lendacky
2023-02-08 19:24 ` Dionna Amalie Glaze
2023-02-08 19:29 ` Borislav Petkov
2023-02-08 19:30 ` Dionna Amalie Glaze
2023-01-24 21:14 ` [PATCH v13 2/4] crypto: ccp - Name -1 return value as SEV_RET_NO_FW_CALL Dionna Glaze
2023-01-24 21:14 ` [PATCH v13 3/4] x86/sev: Change snp_guest_issue_request's fw_err Dionna Glaze
2023-01-24 21:14 ` [PATCH v13 4/4] virt: sev-guest: self-throttle guest request retries Dionna Glaze
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=Y9emVjoTBrM2+Y5P@zn.tnic \
--to=bp@alien8.de \
--cc=Thomas.Lendacky@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=hpa@zytor.com \
--cc=jroedel@suse.de \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=sterritt@google.com \
--cc=tglx@linutronix.de \
--cc=venu.busireddy@oracle.com \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox