On 7/1/2021 1:03 PM, Borislav Petkov wrote:
>
> Sure, but I'd call it sevguest.c and will have it deal with both SEV and
> SNP ioctls depending on what has been detected in the hardware. Or is
> there some special reason for having snp.c and sev.c separate?
>
I don't have any strong reason. I am okay to begin putting all the SNP
stuff in the sevguest.c.
>> I followed the naming convension you recommended during the initial SEV driver
>> developement. IIRC, the main reason for us having to add "user" in it because
>> we wanted to distinguious that this structure is not exactly same as the what
>> is defined in the SEV-SNP firmware spec.
>
> I most definitely have forgotten about this. Can you point me to the
> details of that discussion and why there's a need to distinguish?
>
>> Good question, I am not able to find a generic place to document it. Should we
>> create a documentation "Documentation/virt/coco/sevguest-api.rst" for it ? I am
>> open to other suggestions.
>
The spec definition is present in include/linux/psp-sev.h but sometime we don't
expose the spec defs as-is to userspace. Several SEV/SEV-SNP does not need to
be exposed to the userspace, those which need to be expose we provide a bit
modified Linux uapi for it, and for SEV drivers we choose "_user" prefix.
e.g
a spec definition for the PEK import in include/linux/psp-sev.h is:
struct sev_data_pek_cert_import {
u64 pdh_cert_address; /* system physical address */
u32 pdh_cert_len;
u32 reserved;
...
};
But its corresponding userspace structure def in include/uapi/linux/psp-sev.h is:
struct sev_user_data_pek_cert_import {
__u64 pek_cert_uaddr; /* userspace address */
__u32 pek_cert_len;
...
};
The ioctl handling takes care of mapping from uaddr to pa and other things as required.
So, I took similar approach for the SEV-SNP guest ioctl. In this particular case the
guest request structure defined in the spec contains multiple field but many of
those fields are managed internally by the kernel (e.g seqno, IV, etc etc).
-Brijesh
-Brijesh
