On 6/2/24 04:54, Kirill A. Shutemov wrote:
> Sean observed that the compiler is generating inefficient code to clear
> the tdx_module_args struct for TDCALL and SEAMCALL wrappers. The
> compiler is generating numerous instructions at each call site to clear
> the unused fields of the structure.
>
On 5/22/24 19:24, Dexuan Cui wrote:
...
> +static bool noinstr intel_cc_platform_td_l2(enum cc_attr attr)
> +{
> + switch (attr) {
> + case CC_ATTR_GUEST_MEM_ENCRYPT:
> + case CC_ATTR_MEM_ENCRYPT:
> + return true;
> + default:
> + return false;
> + }
>
On 5/20/24 03:32, Kirill A. Shutemov wrote:
>> In other words, I think this as the foundational justification for the
>> rest of the series leaves a little to be desired.
> See the patch below. Is it what you had in mind?
>
> This patch saves ~2K of code, comparing to ~3K for my patchset:
>
>
Let's say you're debugging tdg_vm_rd(). You suspect someone read the
spec wrong. You pull up the spec:
https://sr71.net/~dave/intel/tdg.vm.rd.png
On 5/17/24 07:19, Kirill A. Shutemov wrote:
> static inline u64 tdg_vm_rd(u64 field, u64 *value)
> {
> - struct tdx_module_args args =
On 5/17/24 07:19, Kirill A. Shutemov wrote:
> - /*
> - * TDINFO TDX module call is used to get the TD execution environment
> - * information like GPA width, number of available vcpus, debug mode
> - * information, etc. More details about the ABI can be found in TDX
> - *
On 5/17/24 07:19, Kirill A. Shutemov wrote:
> static inline void tdx_io_out(int size, u16 port, u32 value)
> {
> - struct tdx_module_args args = {
> - .r10 = TDX_HYPERCALL_STANDARD,
> - .r11 = hcall_func(EXIT_REASON_IO_INSTRUCTION),
> - .r12 = size,
> -
On 5/17/24 07:19, Kirill A. Shutemov wrote:
> TDCALL calls are centralized into a few megawrappers that take the
> struct tdx_module_args as input. Most of the call sites only use a few
> arguments, but they have to zero out unused fields in the structure to
> avoid data leaks to the VMM. This
On 5/17/24 07:19, Kirill A. Shutemov wrote:
> arch/x86/boot/compressed/tdx.c| 32 +---
> arch/x86/coco/tdx/tdcall.S| 145 ++-
> arch/x86/coco/tdx/tdx-shared.c| 26 +--
> arch/x86/coco/tdx/tdx.c | 298 --
> arch/x86/hyperv/ivm.c
On 8/24/23 01:07, Dexuan Cui wrote:
> +#ifdef CONFIG_INTEL_TDX_GUEST
> +static void hv_tdx_msr_write(u64 msr, u64 val)
> +{
> + struct tdx_hypercall_args args = {
> + .r10 = TDX_HYPERCALL_STANDARD,
> + .r11 = EXIT_REASON_MSR_WRITE,
> + .r12 = msr,
> +
On 11/9/23 08:35, Jeremi Piotrowski wrote:
> On 09/11/2023 17:25, Dave Hansen wrote:
>> On 11/9/23 08:14, Jeremi Piotrowski wrote:
>> ...
>>> pr_info("Memory Encryption Features active:");
>>>
>>> - if (cpu_feature_enabled(X86_FEATURE_TD
On 11/9/23 08:14, Jeremi Piotrowski wrote:
...
> pr_info("Memory Encryption Features active:");
>
> - if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
> + if (cc_vendor == CC_VENDOR_INTEL) {
> pr_cont(" Intel TDX\n");
> return;
> }
Why aren't
On 10/20/23 13:00, Dexuan Cui wrote:
>> OK, then what good is this patch in the first place? If you are right,
>> then this would give equivalent information:
>>
>> cat /proc/cpuinfo | grep -q Intel && echo 'TDX'
>> cat /proc/cpuinfo | grep -q AMD && echo 'SEV'
>>
>> No kernel patching needed,
On 10/19/23 23:01, Dexuan Cui wrote:
> This patch only modifies x86 related files. I think it's unlikely to see
> a third hardware Coco implementation for x86 in the foreseeable feature (?)
OK, then what good is this patch in the first place? If you are right,
then this would give equivalent
> --- a/arch/x86/hyperv/ivm.c
> +++ b/arch/x86/hyperv/ivm.c
> @@ -450,6 +450,16 @@ static bool hv_is_private_mmio(u64 addr)
> return false;
> }
>
> +static void hv_print_mem_enc_feature_info(void)
> +{
> + enum hv_isolation_type type = hv_get_isolation_type();
> +
> + if (type ==
14 matches
Mail list logo
