lkml.org 
[lkml]   [2022]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 1/2] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support
    On Fri, Aug 12, 2022 at 09:11:25AM -0500, Tom Lendacky wrote:
    > There was a whole discussion on this

    Pointer to it?

    > and I would prefer to keep the ability to parallelize PSC without
    > locking.

    So smaller, on-stack PSC but lockless is still better than a bigger one
    but with synchronized accesses to it?

    > Well when we don't know which GHCB is in use, using that reserved area in
    > the GHCB doesn't help.

    What do you mean?

    The one which you read with

    data = this_cpu_read(runtime_data);

    in snp_register_per_cpu_ghcb() is the one you register.

    > Also, I don't want to update the GHCB specification for a single bit
    > that is only required because of the way Linux went about establishing
    > the GHCB usage.

    Linux?

    You mean, you did it this way: 885689e47dfa1499b756a07237eb645234d93cf9

    :-)

    "The runtime handler needs one GHCB per-CPU. Set them up and map them
    unencrypted."

    Why does that handler need one GHCB per CPU?

    As to the field, I was thinking along the lines of

    struct ghcb.vendor_flags

    field which each virt vendor can use however they like.

    It might be overkill but a random bool ain't pretty either. Especially
    if those things start getting added for all kinds of other things.

    If anything, you could make this a single u64 sev_flags which can at
    least collect all that gunk in one variable ... at least...

    Thx.

    --
    Regards/Gruss,
    Boris.

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

    \
     
     \ /
      Last update: 2022-08-12 16:34    [W:4.098 / U:26.696 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site