lkml.org 
[lkml]   [2022]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH Part2 v6 11/49] crypto:ccp: Define the SEV-SNP commands
    On Mon, Jun 20, 2022 at 11:04:14PM +0000, Ashish Kalra wrote:
    > +/**
    > + * struct sev_data_snp_platform_status_buf - SNP_PLATFORM_STATUS command params
    > + *
    > + * @address: physical address where the status should be copied
    > + */
    > +struct sev_data_snp_platform_status_buf {
    > + u64 status_paddr; /* In */
    > +} __packed;
    > +
    > +/**
    > + * struct sev_data_snp_download_firmware - SNP_DOWNLOAD_FIRMWARE command params
    > + *
    > + * @address: physical address of firmware image
    > + * @len: len of the firmware image
    > + */
    > +struct sev_data_snp_download_firmware {
    > + u64 address; /* In */
    > + u32 len; /* In */
    > +} __packed;
    > +
    > +/**
    > + * struct sev_data_snp_gctx_create - SNP_GCTX_CREATE command params
    > + *
    > + * @gctx_paddr: system physical address of the page donated to firmware by
    > + * the hypervisor to contain the guest context.
    > + */
    > +struct sev_data_snp_gctx_create {
    > + u64 gctx_paddr; /* In */
    > +} __packed;

    So some of those structs have the same layout. Let's unify them pls.
    I.e., for

    sev_data_send_finish, sev_data_send_cancel, sev_data_receive_finish

    you do

    struct sev_data_tx {
    u32 handle; /* In */
    } __packed;

    For sev_data_snp_platform_status_buf, sev_data_snp_gctx_create,
    sev_data_snp_decommission and all those others who are a single u64, you
    use a single

    struct sev_data_addr {
    u64 gctx_paddr; /* In */
    } __packed;

    so that we don't have gazillion structs all of different names but a lot
    of them identical in content.


    ...

    > +/**
    > + * struct sev_data_snp_launch_finish - SNP_LAUNCH_FINISH command params
    > + *
    > + * @gctx_addr: system pphysical address of guest context page
    ^^^^^^^^^

    physical

    > + */
    > +struct sev_data_snp_launch_finish {
    > + u64 gctx_paddr;
    > + u64 id_block_paddr;
    > + u64 id_auth_paddr;
    > + u8 id_block_en:1;
    > + u8 auth_key_en:1;
    > + u64 rsvd:62;
    > + u8 host_data[32];
    > +} __packed;
    > +
    > +/**
    > + * struct sev_data_snp_guest_status - SNP_GUEST_STATUS command params
    > + *
    > + * @gctx_paddr: system physical address of guest context page
    > + * @address: system physical address of guest status page
    > + */
    > +struct sev_data_snp_guest_status {
    > + u64 gctx_paddr;
    > + u64 address;
    > +} __packed;
    > +
    > +/**
    > + * struct sev_data_snp_page_reclaim - SNP_PAGE_RECLAIM command params
    > + *
    > + * @paddr: system physical address of page to be claimed. The BIT0 indicate
    > + * the page size. 0h indicates 4 kB and 1h indicates 2 MB page.
    > + */
    > +struct sev_data_snp_page_reclaim {
    > + u64 paddr;
    > +} __packed;
    > +
    > +/**
    > + * struct sev_data_snp_page_unsmash - SNP_PAGE_UNMASH command params
    > + *
    > + * @paddr: system physical address of page to be unmashed. The BIT0 indicate

    Is "BIT0" the 0th bit in the address? This needs to be spelled out
    explicitly.

    also, s/unmash/unsmash/gi

    Also, FW SPEC says bits 11:0 are MBZ. So I'm guessing bit 0 is being
    cleared before sending it to sw. I guess I'll see that later.

    Thx.

    --
    Regards/Gruss,
    Boris.

    https://people.kernel.org/tglx/notes-about-netiquette

    \
     
     \ /
      Last update: 2022-09-20 15:05    [W:4.059 / U:1.932 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site