On 17/07/19 19:05, Eric Hankland wrote:
>> Let's just implement the bitmap of fixed counters (it's okay to follow
>> the same action as gp counters), and add it to struct
>> kvm_pmu_event_filter. While at it, we can add a bunch of padding u32s
>> and a flags field that can come in handy later (it
> Let's just implement the bitmap of fixed counters (it's okay to follow
> the same action as gp counters), and add it to struct
> kvm_pmu_event_filter. While at it, we can add a bunch of padding u32s
> and a flags field that can come in handy later (it would fail the ioctl
> if nonzero).
>
>
On 16/07/19 10:49, Wei Wang wrote:
> {
> KVM_PMU_EVENT_ACTION_GP_NONE = 0,
> KVM_PMU_EVENT_ACTION_GP_ACCEPT = 1,
> KVM_PMU_EVENT_ACTION_GP_REJECT = 2,
> KVM_PMU_EVENT_ACTION_MAX
> };
>
> and add comments to explain something like below:
>
> Those GP actions are for the filtering of guest
On 07/16/2019 08:10 AM, Eric Hankland wrote:
I think just disabling guest cpuid might not be enough, since guest
could write to the msr without checking the cpuid.
Why not just add a bitmap for fixed counter?
e.g. fixed_counter_reject_bitmap
At the beginning of reprogram_fixed_counter, we
> I think just disabling guest cpuid might not be enough, since guest
> could write to the msr without checking the cpuid.
>
> Why not just add a bitmap for fixed counter?
> e.g. fixed_counter_reject_bitmap
>
> At the beginning of reprogram_fixed_counter, we could add the check:
>
> if
On 07/11/2019 09:25 AM, Eric Hankland wrote:
- Add a VM ioctl that can control which events the guest can monitor.
Signed-off-by: ehankland
---
Changes since v1:
-Moved to a vm ioctl rather than a vcpu one
-Changed from a whitelist to a configurable filter which can either be
white or black
On 11/07/19 19:04, Eric Hankland wrote:
> Thanks for your help. The "type"->"action" change and constant
> renaming sound good to me.
Good! Another thing, synchronize_rcu is a bit slow for something that
runs whenever a VM starts. KVM generally uses srcu instead (kvm->srcu
for things that
Thanks for your help. The "type"->"action" change and constant
renaming sound good to me.
On Thu, Jul 11, 2019 at 4:58 AM Paolo Bonzini wrote:
>
> On 11/07/19 03:25, Eric Hankland wrote:
> > - Add a VM ioctl that can control which events the guest can monitor.
>
> ... and finally:
>
> - the
On 11/07/19 03:25, Eric Hankland wrote:
> - Add a VM ioctl that can control which events the guest can monitor.
... and finally:
- the patch whitespace is damaged
- the filter is leaked when the VM is destroyed
- kmalloc(GFP_KERNEL_ACCOUNT) is preferrable to vmalloc because it
accounts memory
On 11/07/19 03:25, Eric Hankland wrote:
>
> +/* for KVM_CAP_PMU_EVENT_FILTER */
> +struct kvm_pmu_event_filter {
> + __u32 type;
> + __u32 nevents;
> + __u64 events[0];
> +};
> +
> +#define KVM_PMU_EVENT_WHITELIST 0
> +#define KVM_PMU_EVENT_BLACKLIST 1
> +
"type" is a bit
- Add a VM ioctl that can control which events the guest can monitor.
Signed-off-by: ehankland
---
Changes since v1:
-Moved to a vm ioctl rather than a vcpu one
-Changed from a whitelist to a configurable filter which can either be
white or black
-Only restrict GP counters since fixed counters
11 matches
Mail list logo
