[lkml]   [2021]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest driver
    On Thu, Jul 01, 2021 at 04:32:25PM -0500, Brijesh Singh wrote:
    > The spec definition is present in include/linux/psp-sev.h but sometime
    > we don't expose the spec defs as-is to userspace.


    Having such undocumented and maybe unwarranted differences - I still
    don't see a clear reason why - is calling for additional and unnecessary

    > 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.

    Is that documented somewhere?

    Because "user" doesn't tell me it is a modified structure which is
    different from the spec.

    > 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;
    > ...
    > };

    And the difference is a single "u32 reserved"?

    Dunno, from where I'm standing this looks like unnecessary confusion to

    > 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).

    Ok, multiple fields sounds like you wanna save on the data that is
    shovelled between kernel and user space and then some of the fields
    don't mean a thing for the user API. Ok.

    But again, where is this documented and stated clear so that people are

    Or are you assuming that since the user counterparts are in


    and it being an uapi header, then that should state that?


     \ /
      Last update: 2021-07-03 18:20    [W:2.571 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site