[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc642000-7db8-9944-e57e-db54f0d1336d@intel.com>
Date: Fri, 31 Mar 2023 14:59:18 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Zhi Wang <zhi.wang.linux@...il.com>, isaku.yamahata@...el.com
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
isaku.yamahata@...il.com, Paolo Bonzini <pbonzini@...hat.com>,
erdemaktas@...gle.com, Sean Christopherson <seanjc@...gle.com>,
Sagi Shahar <sagis@...gle.com>,
David Matlack <dmatlack@...gle.com>,
Kai Huang <kai.huang@...el.com>,
Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [PATCH v13 016/113] KVM: TDX: x86: Add ioctl to get TDX
systemwide parameters
On 3/25/2023 4:43 PM, Zhi Wang wrote:
> On Sun, 12 Mar 2023 10:55:40 -0700
> isaku.yamahata@...el.com wrote:
>
> Does this have to be a new generic ioctl with a dedicated new x86_ops? SNP
> does not use it at all and all the system-scoped ioctl of SNP going through
> the CCP driver. So getting system-scope information of TDX/SNP will end up
> differently.
>
> Any thought, Sean? Moving getting SNP system-wide information to
> KVM dev ioctl seems not ideal and TDX does not have a dedicated driver like
> CCP. Maybe make this ioctl TDX-specific? KVM_TDX_DEV_OP?
What's the real different of it? For me, it's just renaming
KVM_MEMORY_ENCRYPT_OP to KVM_TDX_DEV_OP and maybe add some error message
if the IOCTL is issued for AMD plaform.
Powered by blists - more mailing lists