Re: [Xen-devel] [PATCH v2 8/9] x86/CPUID: drop INVPCID dependency on PCID
On 18/09/2019 10:10, Jan Beulich wrote: > On 17.09.2019 21:59, Andrew Cooper wrote: >> On 17/09/2019 07:17, Jan Beulich wrote: >>> PCID validly depends on LM, as it can be enabled in Long Mode only. >>> INVPCID, otoh, can be used not only without PCID enabled, but also >>> outside of Long Mode altogether. In both cases its functionality is >>> simply restricted to PCID 0, which is sort of expected as no other PCID >>> can be activated there. >>> >>> Signed-off-by: Jan Beulich >>> Reviewed-by: Roger Pau Monné >>> >>> --- a/xen/tools/gen-cpuid.py >>> +++ b/xen/tools/gen-cpuid.py >>> @@ -218,10 +218,6 @@ def crunch_numbers(state): >>> # >>> # SSE4_2: [POPCNT] >>> >>> -# The INVPCID instruction depends on PCID infrastructure being >>> -# available. >>> -PCID: [INVPCID], >> I take it you haven't tried running a shadow guest with this change in >> place. >> >> For !EPT, we clear ENABLE_INVPCID so the instruction will #UD within the >> guest. >> >> We could in principle allow the use of INVPCID with shadow guests, but >> that would involve teaching Xen how to cope with VMEXIT_REASON_INVPCID >> (which is predicated on INVLPG exiting) and wire the flush back into the >> shadow logic. >> >> Perhaps the comment could be a little clearer, but it is no accident >> that dependency is in place. > I'm afraid I don't follow: Both features are marked H in the > public header, so I don't see how shadow mode considerations > apply here at all. Oh. Of course. I'm not confused as to why that was present to being with. Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 8/9] x86/CPUID: drop INVPCID dependency on PCID
On 17.09.2019 21:59, Andrew Cooper wrote: > On 17/09/2019 07:17, Jan Beulich wrote: >> PCID validly depends on LM, as it can be enabled in Long Mode only. >> INVPCID, otoh, can be used not only without PCID enabled, but also >> outside of Long Mode altogether. In both cases its functionality is >> simply restricted to PCID 0, which is sort of expected as no other PCID >> can be activated there. >> >> Signed-off-by: Jan Beulich >> Reviewed-by: Roger Pau Monné >> >> --- a/xen/tools/gen-cpuid.py >> +++ b/xen/tools/gen-cpuid.py >> @@ -218,10 +218,6 @@ def crunch_numbers(state): >> # >> # SSE4_2: [POPCNT] >> >> -# The INVPCID instruction depends on PCID infrastructure being >> -# available. >> -PCID: [INVPCID], > > I take it you haven't tried running a shadow guest with this change in > place. > > For !EPT, we clear ENABLE_INVPCID so the instruction will #UD within the > guest. > > We could in principle allow the use of INVPCID with shadow guests, but > that would involve teaching Xen how to cope with VMEXIT_REASON_INVPCID > (which is predicated on INVLPG exiting) and wire the flush back into the > shadow logic. > > Perhaps the comment could be a little clearer, but it is no accident > that dependency is in place. I'm afraid I don't follow: Both features are marked H in the public header, so I don't see how shadow mode considerations apply here at all. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 8/9] x86/CPUID: drop INVPCID dependency on PCID
On 17/09/2019 07:17, Jan Beulich wrote: > PCID validly depends on LM, as it can be enabled in Long Mode only. > INVPCID, otoh, can be used not only without PCID enabled, but also > outside of Long Mode altogether. In both cases its functionality is > simply restricted to PCID 0, which is sort of expected as no other PCID > can be activated there. > > Signed-off-by: Jan Beulich > Reviewed-by: Roger Pau Monné > > --- a/xen/tools/gen-cpuid.py > +++ b/xen/tools/gen-cpuid.py > @@ -218,10 +218,6 @@ def crunch_numbers(state): > # > # SSE4_2: [POPCNT] > > -# The INVPCID instruction depends on PCID infrastructure being > -# available. > -PCID: [INVPCID], I take it you haven't tried running a shadow guest with this change in place. For !EPT, we clear ENABLE_INVPCID so the instruction will #UD within the guest. We could in principle allow the use of INVPCID with shadow guests, but that would involve teaching Xen how to cope with VMEXIT_REASON_INVPCID (which is predicated on INVLPG exiting) and wire the flush back into the shadow logic. Perhaps the comment could be a little clearer, but it is no accident that dependency is in place. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 8/9] x86/CPUID: drop INVPCID dependency on PCID
PCID validly depends on LM, as it can be enabled in Long Mode only. INVPCID, otoh, can be used not only without PCID enabled, but also outside of Long Mode altogether. In both cases its functionality is simply restricted to PCID 0, which is sort of expected as no other PCID can be activated there. Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné --- a/xen/tools/gen-cpuid.py +++ b/xen/tools/gen-cpuid.py @@ -218,10 +218,6 @@ def crunch_numbers(state): # # SSE4_2: [POPCNT] -# The INVPCID instruction depends on PCID infrastructure being -# available. -PCID: [INVPCID], - # XSAVE is an extra set of instructions for state management, but # doesn't constitue new state itself. Some of the dependent features # are instructions built on top of base XSAVE, while others are new ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel