[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SA1PR21MB133593372417A79174325350BFFB9@SA1PR21MB1335.namprd21.prod.outlook.com>
Date: Fri, 6 Jan 2023 15:39:53 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: Zhi Wang <zhi.wang.linux@...il.com>
CC: "ak@...ux.intel.com" <ak@...ux.intel.com>,
"arnd@...db.de" <arnd@...db.de>, "bp@...en8.de" <bp@...en8.de>,
"brijesh.singh@....com" <brijesh.singh@....com>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
"hpa@...or.com" <hpa@...or.com>,
"jane.chu@...cle.com" <jane.chu@...cle.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
KY Srinivasan <kys@...rosoft.com>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"luto@...nel.org" <luto@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
"x86@...nel.org" <x86@...nel.org>,
"Michael Kelley (LINUX)" <mikelley@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"zhi.a.wang@...el.com" <zhi.a.wang@...el.com>
Subject: RE: [PATCH v2 2/6] x86/tdx: Support vmalloc() for
tdx_enc_status_changed()
> From: Zhi Wang <zhi.wang.linux@...il.com>
> Sent: Friday, January 6, 2023 2:11 AM
> To: Dexuan Cui <decui@...rosoft.com>
> [...]
> I guess we both agree that memory conversion in HV should be done through
> coco so the hv_map_memory can be removed (even the extra does not hurt
> currently)
Correct. As I mentioned, Michael's pachset is doing that and hopefully it would
be merged into the upstream soon.
> The memory conversion in current HV code is done by different approaches.
> Some are going through the coco, some are not, which ends up
> with if(hv_isolation_type_snp()) in memory allocation path. It can be
> confusing. I suppose a reasonable purpose of hv_isolation_type_snp()
> should cover the AMD SEV-SNP specific parts which haven't been (or are
> not going to be) covered by coco. For example the GHCB stuff.
>
> Thanks,
> Zhi.
Exactly.
Powered by blists - more mailing lists