[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL1PR11MB5978DB988E482B8329339881F79E9@BL1PR11MB5978.namprd11.prod.outlook.com>
Date: Fri, 5 Aug 2022 00:03:57 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: David Matlack <dmatlack@...gle.com>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>
CC: kvm list <kvm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Isaku Yamahata <isaku.yamahata@...il.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"Aktas, Erdem" <erdemaktas@...gle.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"Shahar, Sagi" <sagis@...gle.com>
Subject: RE: [RFC PATCH v6 037/104] KVM: x86/mmu: Allow non-zero value for
non-present SPTE
> > In addition to the suggestions above, I'd suggest breaking this patch
> > up, since it is doing multiple things:
> >
> > 1. Patch initialize shadow page tables to EMPTY_SPTE (0) and
> > replace TDP MMU hard-coded 0 with EMPTY_SPTE.
> > 2. Patch to change FNAME(sync_page) to not assume EMPTY_SPTE is 0.
> > 3. Patch to set bit 63 in EMPTY_SPTE.
> > 4. Patch to set bit 63 in REMOVED_SPTE.
I think 1/2 can be separate patches, but 3/4 should be done together.
Patch 3 alone is broken as when TDP MMU zaps SPTE and replaces it with REMOVED_SPTE, it loses bit 63. This is not what we want. We always want bit 63 set if it is supposed to be set to a non-present SPTE.
But I also don't see splitting to 3 patches is absolutely worth to do as doing above in one patch is also fine to me.
Powered by blists - more mailing lists