On 03/02/2010 07:17 PM, Ingo Molnar wrote:
* Paolo Bonzinipbonz...@redhat.com wrote:
On 02/26/2010 03:23 PM, Ingo Molnar wrote:
I do think tools/X and tools/libc would make quite a bit of sense - this is
one of the better design aspects of FreeBSD et al. It's a mistake that it's
On 02/26/2010 03:23 PM, Ingo Molnar wrote:
I do think tools/X and tools/libc would make quite a bit of sense - this is
one of the better design aspects of FreeBSD et al. It's a mistake that it's
not being done.
I don't see what it would buy to have tools/libc. You cannot force
users to
Em Tue, Mar 02, 2010 at 05:46:03PM +0100, Paolo Bonzini escreveu:
On 02/26/2010 03:23 PM, Ingo Molnar wrote:
I do think tools/X and tools/libc would make quite a bit of sense - this is
one of the better design aspects of FreeBSD et al. It's a mistake that it's
not being done.
I don't see
* Paolo Bonzini pbonz...@redhat.com wrote:
On 02/26/2010 03:23 PM, Ingo Molnar wrote:
I do think tools/X and tools/libc would make quite a bit of sense - this is
one of the better design aspects of FreeBSD et al. It's a mistake that it's
not being done.
I don't see what it would buy to
On 03/02/2010 06:12 PM, Arnaldo Carvalho de Melo wrote:
You imply lockstep updates because both are on the same source tree? I
don't see why that would be required, there is an ABI contract to be
respected no matter where the sources for the signatories live.
It's not about ABIs, it's about
* Paolo Bonzini pbonz...@redhat.com wrote:
On 03/02/2010 06:12 PM, Arnaldo Carvalho de Melo wrote:
You imply lockstep updates because both are on the same source tree? I
don't see why that would be required, there is an ABI contract to be
respected no matter where the sources for the
* Zhang, Yanmin yanmin_zh...@linux.intel.com wrote:
2) We couldn't get guest os kernel/user stack data in an easy way, so we
might not support callchain feature of tool perf. A work around is KVM
copies kernel stack data out, so we could at least support guest os kernel
callchain.
If the
* Avi Kivity a...@redhat.com wrote:
On 02/26/2010 11:01 AM, Ingo Molnar wrote:
* Zhang, Yanminyanmin_zh...@linux.intel.com wrote:
2) We couldn't get guest os kernel/user stack data in an easy way, so we
might not support callchain feature of tool perf. A work around is KVM
copies kernel
On 02/26/2010 12:35 PM, Ingo Molnar wrote:
One additional step needed is to get symbol information from the guest, and to
integrate it into the symbol cache on the host side in ~/.debug. We already
support cross-arch symbols and 'perf archive', so the basic facilities are
there for that. So
* Avi Kivity a...@redhat.com wrote:
Do you have (or plan) any turn-key 'access to all files of the guest' kind
of guest-transparent facility that could be used for such purposes?
Not really. The guest and host admins are usually different people, who
may, being admins, even actively
On 02/26/2010 01:17 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Do you have (or plan) any turn-key 'access to all files of the guest' kind
of guest-transparent facility that could be used for such purposes?
Not really. The guest and host admins are usually
On Fri, 2010-02-26 at 12:47 +0200, Avi Kivity wrote:
Not really. The guest and host admins are usually different people, who
may, being admins, even actively hate each other. The guest admin would
probably regard it as a security hole. It's probably useful for the
single-host scenario,
On 02/26/2010 01:48 PM, Peter Zijlstra wrote:
On Fri, 2010-02-26 at 12:47 +0200, Avi Kivity wrote:
Not really. The guest and host admins are usually different people, who
may, being admins, even actively hate each other. The guest admin would
probably regard it as a security hole. It's
* Avi Kivity a...@redhat.com wrote:
You basically have given up control over the quality of KVM by pushing so
many aspects of it to user-space and letting it rot there.
That's wrong on so many levels. First, nothing is rotting in userspace,
qemu is evolving faster than kvm is. If I
On 02/26/2010 02:46 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
You basically have given up control over the quality of KVM by pushing so
many aspects of it to user-space and letting it rot there.
That's wrong on so many levels. First, nothing is rotting in
On 02/26/10 14:16, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
That was not what i suggested tho. tools/kvm/ would work plenty fine.
I'll wait until we have tools/libc and tools/X. After all, they affect a
lot more people and are concerned with a lot more kernel/user interfaces
On 02/26/2010 03:16 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
That was not what i suggested tho. tools/kvm/ would work plenty fine.
I'll wait until we have tools/libc and tools/X. After all, they affect a
lot more people and are concerned with a lot more
* Avi Kivity a...@redhat.com wrote:
On 02/26/2010 03:16 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
That was not what i suggested tho. tools/kvm/ would work plenty fine.
I'll wait until we have tools/libc and tools/X. After all, they affect a
lot more people and are
On 02/26/2010 04:23 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 02/26/2010 03:16 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
That was not what i suggested tho. tools/kvm/ would work plenty fine.
I'll wait until we have
On 02/26/2010 01:17 PM, Ingo Molnar wrote:
Nobody is really 'in charge' of how KVM gets delivered to the user. You
isolated the fun kernel part for you and pushed out the boring bits to
user-space. So if mundane things like mouse integration sucks 'hey that's a
user-space tooling problem', if
On 02/26/2010 04:35 AM, Ingo Molnar wrote:
Basically what is needed is plain filesystem access - properly privileged. So
doing this via a vmchannel would be nice, but for the symbol extraction it
would be a glorified NFS server in essence.
Do you have (or plan) any turn-key 'access to all files
On Thu, 2010-02-25 at 10:20 +0100, Peter Zijlstra wrote:
On Thu, 2010-02-25 at 11:27 +0800, Zhang, Yanmin wrote:
Ingo,
I did some testing with KVM virtualization. perf shows vmx_vcpu_run
consumes more than 50% cpu time. Actually, the info is incorrect because
when perf counter
22 matches
Mail list logo
