From: Andrew Jones <ajones@ventanamicro.com>
To: Atish Patra <atishp@atishpatra.org>
Cc: Atish Patra <atishp@rivosinc.com>,
linux-kernel@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
Anup Patel <anup@brainfault.org>, Guo Ren <guoren@kernel.org>,
kvm-riscv@lists.infradead.org, kvm@vger.kernel.org,
linux-riscv@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Will Deacon <will@kernel.org>
Subject: Re: [RFC 5/9] RISC-V: KVM: Add skeleton support for perf
Date: Wed, 23 Nov 2022 14:36:36 +0100 [thread overview]
Message-ID: <20221123133636.gke3626aolfrnevy@kamzik> (raw)
In-Reply-To: <CAOnJCUKpdV3u8X6BSC+-rhV0Q8q2tdsa8r_KTH5FWCh2LV2q8Q@mail.gmail.com>
...
> > > > - 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
next prev parent reply other threads:[~2022-11-23 13:47 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 17:01 [RFC 0/9] KVM perf support Atish Patra
2022-07-18 17:01 ` [RFC 1/9] RISC-V: Define a helper function to probe number of hardware counters Atish Patra
2022-11-01 12:30 ` Andrew Jones
2022-11-21 23:50 ` Atish Patra
2022-07-18 17:01 ` [RFC 2/9] RISC-V: Define a helper function to return counter width Atish Patra
2022-07-18 17:01 ` [RFC 3/9] RISC-V: KVM: Define a probe function for SBI extension data structures Atish Patra
2022-11-01 15:32 ` Andrew Jones
2022-07-18 17:02 ` [RFC 4/9] RISC-V: KVM: Improve privilege mode filtering for perf Atish Patra
2022-11-01 12:51 ` Andrew Jones
2022-11-09 13:42 ` Sergey Matyukevich
2022-11-22 0:21 ` Atish Patra
2022-07-18 17:02 ` [RFC 5/9] RISC-V: KVM: Add skeleton support " Atish Patra
2022-11-01 14:13 ` Andrew Jones
2022-11-23 0:46 ` Atish Patra
2022-11-23 1:34 ` Atish Patra
2022-11-23 13:36 ` Andrew Jones [this message]
2022-11-24 9:04 ` Atish Patra
2022-11-24 10:55 ` Andrew Jones
2022-11-23 13:11 ` Andrew Jones
2022-11-24 9:09 ` Atish Patra
2022-11-24 11:14 ` Andrew Jones
2022-07-18 17:02 ` [RFC 6/9] RISC-V: KVM: Add SBI PMU extension support Atish Patra
2022-11-01 14:26 ` Andrew Jones
2022-11-22 23:08 ` Atish Patra
2022-11-23 13:58 ` Andrew Jones
2022-11-24 10:18 ` Atish Patra
2022-11-24 10:50 ` Andrew Jones
2022-11-24 12:59 ` Anup Patel
2022-11-28 21:00 ` Atish Patra
2022-07-18 17:02 ` [RFC 7/9] RISC-V: KVM: Implement trap & emulate for hpmcounters Atish Patra
2022-11-01 14:35 ` Andrew Jones
2022-11-22 23:11 ` Atish Patra
2022-07-18 17:02 ` [RFC 8/9] RISC-V: KVM: Implement perf support Atish Patra
2022-09-20 2:24 ` Eric Lin
2022-09-23 21:04 ` Atish Patra
2022-11-01 15:31 ` Andrew Jones
2022-11-23 0:45 ` Atish Patra
2022-11-23 14:22 ` Andrew Jones
2022-12-02 9:08 ` Atish Patra
2022-12-02 11:37 ` Andrew Jones
2022-12-07 8:49 ` Atish Patra
2022-12-02 17:09 ` Sean Christopherson
2022-12-07 8:06 ` Atish Patra
2022-12-07 16:31 ` Sean Christopherson
2022-12-08 1:11 ` Atish Patra
2022-07-18 17:02 ` [RFC 9/9] RISC-V: KVM: Implement firmware events Atish Patra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221123133636.gke3626aolfrnevy@kamzik \
--to=ajones@ventanamicro.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@atishpatra.org \
--cc=atishp@rivosinc.com \
--cc=guoren@kernel.org \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox