[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C206EA0.3060101@redhat.com>
Date: Tue, 22 Jun 2010 11:04:48 +0300
From: Avi Kivity <avi@...hat.com>
To: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
CC: Gleb Natapov <gleb@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, kvm@...r.kernel.org,
Ingo Molnar <mingo@...e.hu>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Lin Ming <ming.m.lin@...el.com>,
Sheng Yang <sheng@...ux.intel.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
oerg Roedel <joro@...tes.org>,
Jes Sorensen <Jes.Sorensen@...hat.com>,
Zachary Amsden <zamsden@...hat.com>, zhiteng.huang@...el.com,
tim.c.chen@...el.com, Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH V2 3/5] ara virt interface of perf to support kvm guest
os statistics collection in guest os
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@...ux.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.
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.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists