On Thu, Nov 24, 2022 at 01:04:15AM -0800, Atish Patra wrote: > On Wed, Nov 23, 2022 at 5:36 AM Andrew Jones <ajones@xxxxxxxxxxxxxxxx> wrote: > > > > ... > > > > > > - csr_write(CSR_HCOUNTEREN, -1UL); > > > > > > + /* VS should access only TM bit. Everything else should trap */ > > > > > > + csr_write(CSR_HCOUNTEREN, 0x02); > > > > > > > > > > This looks like something that should be broken out into a separate patch > > > > > with a description of what happens now when guests try to access the newly > > > > > trapping counter registers. We should probably also create a TM define. > > > > > > > > > > > > > Done. > > > > > > > > > > As we allow cycles & instret for host user space now [1], should we do the same > > > for guests as well ? I would prefer not to but same user space > > > software will start to break > > > they will run inside a guest. > > > > > > https://lore.kernel.org/all/20220928131807.30386-1-palmer@xxxxxxxxxxxx/ > > > > > > > Yeah, it seems like we should either forbid access to unprivileged users > > or ensure the numbers include some random noise. For guests, a privileged > > KVM userspace should need to explicitly request access for them, ensuring > > that the creation of privileged guests is done by conscious choice. > > > > If I understand you correctly, you are suggesting we only enable TM > bit in hcounteren ? Yeah, and also that I think it'd be nice to revisit this for userspace. > We also need a mechanism to enable the hcounteren bits from KVM guest userspace. > > I can think of the following approaches. > > 1. The CYCLE, INSTRET enabling can also be via one reg interface. > 2. We can enable it during first virtual instruction trap if these > bits in guest scounteren > are enabled. Those sound good to me. Thanks, drew
