On 4/5/21 10:06 AM, Sean Christopherson wrote: > On Sun, Apr 04, 2021, Christophe Leroy wrote: >> Le 03/04/2021 à 01:37, Sean Christopherson a écrit : >>> @@ -152,11 +153,21 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret) >>> sev = psp->sev_data; >>> buf_len = sev_cmd_buffer_len(cmd); >>> - if (WARN_ON_ONCE(!!data != !!buf_len)) >>> + if (WARN_ON_ONCE(!!__data != !!buf_len)) >>> return -EINVAL; >>> - if (WARN_ON_ONCE(data && is_vmalloc_addr(data))) >>> - return -EINVAL; >>> + if (__data && is_vmalloc_addr(__data)) { >>> + /* >>> + * If the incoming buffer is virtually allocated, copy it to >>> + * the driver's scratch buffer as __pa() will not work for such >>> + * addresses, vmalloc_to_page() is not guaranteed to succeed, >>> + * and vmalloc'd data may not be physically contiguous. >>> + */ >>> + data = sev->cmd_buf; >>> + memcpy(data, __data, buf_len); >>> + } else { >>> + data = __data; >>> + } >> I don't know how big commands are, but if they are small, it would probably >> be more efficient to inconditionnally copy them to the buffer rather then >> doing the test. > Brijesh, I assume SNP support will need to copy the commands unconditionally? If > yes, it probably makes sense to do so now and avoid vmalloc dependencies > completely. And I think that would allow for the removal of status_cmd_buf and > init_cmd_buf, or is there another reason those dedicated buffers exist? Yes, we need to copy the commands unconditionally for the SNP support. It makes sense to avoid the vmalloc dependencies. I can't think of any reason why we would need the status_cmd_buf and init_cmd_buf after those changes.