[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220412195859.gjklfw3fz2lehpb5@box.shutemov.name>
Date: Tue, 12 Apr 2022 22:58:59 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Andy Lutomirski <luto@...nel.org>
Cc: Chao Peng <chao.p.peng@...ux.intel.com>,
Wanpeng Li <wanpengli@...cent.com>, jun.nakajima@...el.com,
kvm@...r.kernel.org, david@...hat.com, qemu-devel@...gnu.org,
"J . Bruce Fields" <bfields@...ldses.org>, linux-mm@...ck.org,
"H . Peter Anvin" <hpa@...or.com>, ak@...ux.intel.com,
Jonathan Corbet <corbet@....net>,
Joerg Roedel <joro@...tes.org>, x86@...nel.org,
Hugh Dickins <hughd@...gle.com>,
Steven Price <steven.price@....com>,
Ingo Molnar <mingo@...hat.com>,
"Maciej S . Szmigiero" <mail@...iej.szmigiero.name>,
Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Vlastimil Babka <vbabka@...e.cz>,
Jim Mattson <jmattson@...gle.com>, dave.hansen@...el.com,
linux-api@...r.kernel.org, Jeff Layton <jlayton@...nel.org>,
linux-kernel@...r.kernel.org,
Yu Zhang <yu.c.zhang@...ux.intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>,
linux-fsdevel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vishal Annapurve <vannapurve@...gle.com>,
Mike Rapoport <rppt@...nel.org>
Subject: Re: [PATCH v5 00/13] KVM: mm: fd-based approach for supporting KVM
guest private memory
On Mon, Mar 28, 2022 at 01:16:48PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 10, 2022 at 6:09 AM Chao Peng <chao.p.peng@...ux.intel.com> wrote:
> >
> > This is the v5 of this series which tries to implement the fd-based KVM
> > guest private memory. The patches are based on latest kvm/queue branch
> > commit:
> >
> > d5089416b7fb KVM: x86: Introduce KVM_CAP_DISABLE_QUIRKS2
>
> Can this series be run and a VM booted without TDX? A feature like
> that might help push it forward.
It would require enlightenment of the guest code. We have two options.
Simple one is to limit enabling to the guest kernel, but it would require
non-destructive conversion between shared->private memory. This does not
seem to be compatible with current design.
Other option is get memory private from time 0 of VM boot, but it requires
modification of virtual BIOS to setup shared ranges as needed. I'm not
sure if anybody volunteer to work on BIOS code to make it happen.
Hm.
--
Kirill A. Shutemov
Powered by blists - more mailing lists