[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221123133636.gke3626aolfrnevy@kamzik>
Date: Wed, 23 Nov 2022 14:36:36 +0100
From: Andrew Jones <ajones@...tanamicro.com>
To: Atish Patra <atishp@...shpatra.org>
Cc: Atish Patra <atishp@...osinc.com>, linux-kernel@...r.kernel.org,
Albert Ou <aou@...s.berkeley.edu>,
Anup Patel <anup@...infault.org>, Guo Ren <guoren@...nel.org>,
kvm-riscv@...ts.infradead.org, kvm@...r.kernel.org,
linux-riscv@...ts.infradead.org,
Mark Rutland <mark.rutland@....com>,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Will Deacon <will@...nel.org>
Subject: Re: [RFC 5/9] RISC-V: KVM: Add skeleton support for perf
...
> > > > - 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@rivosinc.com/
>
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.
Thanks,
drew
Powered by blists - more mailing lists