lkml.org 
[lkml]   [2010]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH V2 3/5] ara virt interface of perf to support kvm guest os statistics collection in guest os
    From
    Date
    On Tue, 2010-06-22 at 11:04 +0300, Avi Kivity wrote:
    > On 06/22/2010 08:47 AM, Zhang, Yanmin wrote:
    > > On Mon, 2010-06-21 at 16:56 +0300, Gleb Natapov wrote:
    > >
    > >> On Mon, Jun 21, 2010 at 05:31:43PM +0800, Zhang, Yanmin wrote:
    > >>
    > >>> The 3rd patch is to implement para virt perf at host kernel.
    > >>>
    > >>> Signed-off-by: Zhang Yanmin<yanmin_zhang@linux.intel.com>
    > >>>
    > >>>
    > > <snip>
    > >
    > >
    > >>> +
    > >>> +static void kvm_copy_event_to_guest(struct kvm_vcpu *vcpu,
    > >>> + struct perf_event *host_event)
    > >>> +{
    > >>> + struct host_perf_shadow *shadow = host_event->host_perf_shadow;
    > >>> + struct guest_perf_event counter;
    > >>> + int ret;
    > >>> + s32 overflows;
    > >>> +
    > >>> + ret = kvm_read_guest(vcpu->kvm, shadow->guest_event_addr,
    > >>> + &counter, sizeof(counter));
    > >>> + if (ret< 0)
    > >>> + return;
    > >>> +
    > >>> +again:
    > >>> + overflows = atomic_read(&shadow->counter.overflows);
    > >>> + if (atomic_cmpxchg(&shadow->counter.overflows, overflows, 0) !=
    > >>> + overflows)
    > >>> + goto again;
    > >>> +
    > >>> + counter.count = shadow->counter.count;
    > >>> + atomic_add(overflows,&counter.overflows);
    > >>> +
    > >>> + kvm_write_guest(vcpu->kvm,
    > >>> + shadow->guest_event_addr,
    > >>> + &counter,
    > >>> + sizeof(counter));
    > >>>
    > >> Those kind of interfaces worry me since the can cause bugs that are
    > >> very hard to catch. What if guest enables some events and crashes into
    > >> kdump kernel (or kexec new kernel) without reseting HW. Now host may
    > >> write over guest memory without guest expecting it. Do you handle this
    > >> scenario in a guest side? I think you need to register reboot notify
    > >> and disable events from there.
    > >>
    > > Sorry for missing your comments.
    > >
    > > My patch could take care of dead guest os by cleaning up all events in function
    > > kvm_arch_destroy_vm, so all events are closed if host user kills the guest
    > > qemu process.
    > >
    > >
    >
    > A reset does not involve destroying a vm; you have to clean up as part
    > of the rest process.
    What does 'reset' here mean? Is it a reboot or halt? If it's a halt, it involves
    destroying a vm. If a host user just kills the qemu process, is it a reset involving
    destroying a vm?

    >
    > Note MSRs are automatically cleared, so that's something in favour of an
    > MSR interface.
    >
    > > As for your scenario, I will register reboot notify and add a new pv perf
    > > hypercall interface to vmexit to host kernel to do cleanup.
    > >
    >
    > You aren't guaranteed a reboot notifier will be called. On the other
    > hand, we need a kexec handler.
    ordinary kexec calls all reboot notifiers. Only crash kexec doesn't call them.
    I will implement a machine_ops.crash_shutdown callback.




    \
     
     \ /
      Last update: 2010-06-23 03:45    [W:0.030 / U:0.772 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site