On Wed, 2023-12-06 at 18:07 +0300, kirill.shute...@linux.intel.com
wrote:
> I can't think of any non-ridiculous way to handle this case. Maybe
> we
> > need VMM help.
>
> Do you see a specific way how VMM can help here?
I didn't have a specific idea. I was just thinking that the problem is
that
On Wed, Dec 06, 2023 at 01:28:08AM +, Edgecombe, Rick P wrote:
> On Tue, 2023-12-05 at 03:45 +0300, Kirill A. Shutemov wrote:
> > +static void tdx_kexec_unshare_mem(bool crash)
> > +{
> > + unsigned long addr, end;
> > + long found = 0, shared;
> > +
> > + /* Stop new
On Tue, 2023-12-05 at 03:45 +0300, Kirill A. Shutemov wrote:
> +static void tdx_kexec_unshare_mem(bool crash)
> +{
> + unsigned long addr, end;
> + long found = 0, shared;
> +
> + /* Stop new private<->shared conversions */
> + conversion_allowed = false;
I wonder if this
TDX guests allocate shared buffers to perform I/O. It is done by
allocating pages normally from the buddy allocator and converting them
to shared with set_memory_decrypted().
The second kernel has no idea what memory is converted this way. It only
sees E820_TYPE_RAM.
Accessing shared memory via
