Re: [PATCH] x86/sev: Remove bogus virtual address check

[Alexey Kardashevskiy <aik@amd.com>]

On 1/4/26 00:21, Ard Biesheuvel wrote:
> (add Eric back to cc)
> 
> Please keep Eric on cc - I added him for a reason, thanks.
> 
> 
> On Tue, 31 Mar 2026, at 15:18, Ard Biesheuvel wrote:
>> On Tue, 31 Mar 2026, at 15:16, Borislav Petkov wrote:
>>> On Fri, Oct 10, 2025 at 05:10:37PM +0200, Ard Biesheuvel wrote:
>>>> From: Ard Biesheuvel <ardb@kernel.org>
>>>>
>>>> The AES-GCM crypto library operates strictly on virtual addresses, and
>>>> never performs any H/W offload, and so calling virt_addr_valid() is not
>>>> needed.
>>>>
>>>> Cc: Borislav Petkov (AMD) <bp@alien8.de>
>>>> Cc: Tom Lendacky <thomas.lendacky@amd.com>
>>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>>>> ---
>>>>   arch/x86/coco/sev/core.c | 9 ---------
>>>>   1 file changed, 9 deletions(-)
>>>>
>>>> diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
>>>> index 9ae3b11754e6..c4e2de3687a9 100644
>>>> --- a/arch/x86/coco/sev/core.c
>>>> +++ b/arch/x86/coco/sev/core.c
>>>> @@ -2249,15 +2249,6 @@ int snp_send_guest_request(struct snp_msg_desc *mdesc, struct snp_guest_req *req
>>>>   	u64 seqno;
>>>>   	int rc;
>>>>   
>>>> -	/*
>>>> -	 * enc_payload() calls aesgcm_encrypt(), which can potentially offload to HW.
>>>> -	 * The offload's DMA SG list of data to encrypt has to be in linear mapping.
>>>> -	 */
>>>> -	if (!virt_addr_valid(req->req_buf) || !virt_addr_valid(req->resp_buf)) {
>>>> -		pr_warn("AES-GSM buffers must be in linear mapping");
>>>> -		return -EINVAL;
>>>> -	}
>>>> -
>>>>   	guard(mutex)(&snp_cmd_mutex);
>>>>   
>>>>   	/* Check if the VMPCK is not empty */
>>>> -- 
>>>
>>> This came from:
>>>
>>>    7ffeb2fc2670 ("x86/sev: Document requirement for linear mapping of
>>> guest request buffers")

Nah, this is because of
db10cb9b574675402b virt: sevguest: Fix passing a stack buffer as a scatterlist target


>>>
>>> and there was some speculation about the potential of using a crypto
>>> accelerator which wants addresses in linear mapping...

If the pr_warn() above is removed, then we get this BUG_ON back:

===
static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
                               unsigned int buflen)
{
#ifdef CONFIG_DEBUG_SG
         BUG_ON(!virt_addr_valid(buf));
#endif
         sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
}
===

So if you really insist on removing my pr_warn(), then post a patch removing the BUG_ON too. Thanks,

>>>
>>
>> Sure, but that speculation was entirely misguided, so we can remove this again.

-- 
Alexey