| Message ID | fc21565a-3cb1-4547-09a2-fc908a51e526@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | XSA-292 follow-up | expand |
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 <jbeulich@suse.com> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> > > --- 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
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 <jbeulich@suse.com> >> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> >> >> --- 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
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 <jbeulich@suse.com> >>> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> >>> >>> --- 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 <andrew.cooper3@citrix.com>
--- 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