[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a4a83fd2-b1e6-3dce-6881-8abe71c7e934@amd.com>
Date: Tue, 31 Jan 2023 08:38:31 +0530
From: "Nikunj A. Dadhania" <nikunj@....com>
To: Dionna Amalie Glaze <dionnaglaze@...gle.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, bp@...en8.de,
thomas.lendacky@....com, pgonda@...gle.com, jroedel@...e.de,
mingo@...hat.com, tglx@...utronix.de, dave.hansen@...ux.intel.com,
seanjc@...gle.com, pbonzini@...hat.com, michael.roth@....com,
ketanch@...k.ac.in
Subject: Re: [RFC PATCH 03/11] virt: sev-guest: Add snp_guest_req structure
On 31/01/23 00:15, Dionna Amalie Glaze wrote:
>> +static int snp_send_guest_request(struct snp_guest_dev *snp_dev, struct snp_guest_req *req)
>> {
>> unsigned long err;
>> u64 seqno;
>> int rc;
>>
>> + if (!snp_dev || !req)
>> + return -ENODEV;
>> +
>> /* Get message sequence and verify that its a non-zero */
>> seqno = snp_get_msg_seqno(snp_dev);
>> if (!seqno)
>> @@ -261,7 +253,7 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>> memset(snp_dev->response, 0, sizeof(struct snp_guest_msg));
>>
>> /* Encrypt the userspace provided payload */
>> - rc = enc_payload(snp_dev, seqno, msg_ver, type, req_buf, req_sz);
>> + rc = enc_payload(snp_dev, seqno, req, vmpck_id);
>> if (rc)
>> return rc;
>>
>> @@ -271,7 +263,7 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>> * sequence number must be incremented or the VMPCK must be deleted to
>> * prevent reuse of the IV.
>> */
>> - rc = snp_issue_guest_request(exit_code, &snp_dev->input, &err);
>> + rc = snp_issue_guest_request(req->exit_code, &snp_dev->input, &err);
>>
>> /*
>> * If the extended guest request fails due to having too small of a
>> @@ -279,11 +271,11 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>> * extended data request in order to increment the sequence number
>> * and thus avoid IV reuse.
>> */
>> - if (exit_code == SVM_VMGEXIT_EXT_GUEST_REQUEST &&
>> + if (req->exit_code == SVM_VMGEXIT_EXT_GUEST_REQUEST &&
>> err == SNP_GUEST_REQ_INVALID_LEN) {
>> const unsigned int certs_npages = snp_dev->input.data_npages;
>>
>> - exit_code = SVM_VMGEXIT_GUEST_REQUEST;
>> + req->exit_code = SVM_VMGEXIT_GUEST_REQUEST;
>>
>> /*
>> * If this call to the firmware succeeds, the sequence number can
>> @@ -293,7 +285,7 @@ static int handle_guest_request(struct snp_guest_dev *snp_dev, u64 exit_code, in
>> * of the VMPCK and the error code being propagated back to the
>> * user as an ioctl() return code.
>> */
>> - rc = snp_issue_guest_request(exit_code, &snp_dev->input, &err);
>> + rc = snp_issue_guest_request(req->exit_code, &snp_dev->input, &err);
>>
>
> This is going to have a merge conflict with "[PATCH v13 1/4]
> virt/coco/sev-guest: Add throttling awareness", which is an important
> fix to ensure hosts are allowed to throttle guest requests and guests
> are able to retry instead of disabling the vmpck. I think that set of
> patches, or at least the first patch, is going to be going in before
> this series. Please be aware.
Yes, I am aware of the series. I can rebase my patches once that goes in.
Regards
Nikunj
Powered by blists - more mailing lists