On 03/21/2010 11:20 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Well, for what it's worth, I rarely ever use anything else. My virtual
disks are raw so I can loop mount them easily, and I can also switch my
guest kernels from outside... without ever needing to mount those
On 03/21/2010 10:37 PM, Ingo Molnar wrote:
That includes the guest kernel. If you can deploy a new kernel in the
guest, presumably you can deploy a userspace package.
Note that with perf we can instrument the guest with zero guest-kernel
modifications as well.
We try to reduce the
On 03/21/2010 11:52 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
I.e. you are arguing for microkernel Linux, while you see me as arguing
for a monolithic kernel.
No. I'm arguing for reducing bloat wherever possible. Kernel code is more
expensive than userspace code
On 03/21/2010 11:54 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/21/2010 10:55 PM, Ingo Molnar wrote:
Of course you could say the following:
' Thanks, I'll mark this for v2.6.36 integration. Note that we are not
able to add this to the v2.6.35 kernel
On 03/22/2010 12:00 AM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Consider the _other_ examples that are a lot more clear:
' If you expose paravirt spilocks via KVM please also make sure the KVM
tooling can make use of it, has an option for it to configure it, and
On 03/22/2010 10:35 AM, Michael Tokarev wrote:
Paul Brook wrote at Wed, 17 Mar 2010 11:18:09 +:
Oh, well, yes, I remember. qemu is more strict on ISA irq sharing now.
A bit too strict.
/me goes dig out a old patch which never made it upstream for some
reason I forgot. Attached.
On 03/22/2010 01:14 PM, Ingo Molnar wrote:
I think we agree at last. Neither I nor my employer are interested in
running qemu as a desktop-on-desktop tool, therefore I don't invest any
effort in that direction, or require it from volunteers.
Obviously your employer at least in part
On 03/22/2010 01:48 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
My 10+ years experience with kernel instrumentation solutions is that
kernel-driven, self-sufficient, robust, trustable, well-enumerated sources
of information work far better in practice.
What about
On 03/22/2010 01:39 PM, Ingo Molnar wrote:
Reality is, the server space never was and never will be self-sustaining in
the long run (as Novell has found it out with Netware), it is the desktop that
dictates future markets. This is why i find your views about this naive and
shortsighted.
On 03/22/2010 01:23 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
IMO the reason perf is more usable than oprofile has less to do with the
kernel/userspace boundary and more do to with effort and attention spent on
the userspace/user boundary.
[...]
If you are
On 03/22/2010 02:44 PM, Ingo Molnar wrote:
This is why i consider that line of argument rather dishonest ...
I am not going to reply to any more email from you on this thread.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line
On 03/22/2010 04:32 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/22/2010 02:44 PM, Ingo Molnar wrote:
This is why i consider that line of argument rather dishonest ...
I am not going to reply to any more email from you on this thread.
Because i
On 03/22/2010 06:08 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/22/2010 04:32 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/22/2010 02:44 PM, Ingo Molnar wrote:
This is why i consider that line of argument rather
On 03/22/2010 06:12 PM, Avi Kivity wrote:
There were a few responses to that but none really addressed those
problems -
they mostly tried to re-define the problem and suggested that i was
wrong to
want such capabilities and suggested various inferior approaches
instead. See
the thread
On 03/22/2010 06:51 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
The crux of the problem is very simple. To quote my earlier mail:
|
| - The inconvenience of having to type:
| perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms \
|
On 03/22/2010 04:26 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/22/2010 01:39 PM, Ingo Molnar wrote:
Reality is, the server space never was and never will be self-sustaining
in the long run (as Novell has found it out with Netware), it is the
desktop that
On 03/22/2010 07:27 PM, Pekka Enberg wrote:
It's kinda funny to see people argue that having an external
repository is not a problem and that it's not a big deal if building
something from the repository is slightly painful as long as it
doesn't require a PhD when we have _real world_ experience
On 03/22/2010 06:32 PM, Ingo Molnar wrote:
So, what do you think creates code communities and keeps them alive?
Developers and code. And the wellbeing of developers are primarily influenced
by the repository structure and by the development/maintenance process - i.e.
by the 'fun' aspect. (i'm
On 03/22/2010 07:34 PM, Ingo Molnar wrote:
The 'something trustable and kernel-provided'. The kernel knows nothing
about guest names.
The kernel certainly knows about other resources such as task names or network
interface names or tracepoint names. This is kernel design 101.
But
On 03/22/2010 07:39 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/22/2010 07:27 PM, Pekka Enberg wrote:
It's kinda funny to see people argue that having an external repository is
not a problem and that it's not a big deal if building something from the
repository
On 03/22/2010 07:43 PM, Ingo Molnar wrote:
It's kinda funny to see people argue that having an external repository is
not a problem and that it's not a big deal if building something from the
repository is slightly painful as long as it doesn't require a PhD when we
have _real world_
On 03/22/2010 07:52 PM, Pekka Enberg wrote:
Hi Avi,
On Mon, Mar 22, 2010 at 7:32 PM, Avi Kivitya...@redhat.com wrote:
It's kinda funny to see people argue that having an external
repository is not a problem and that it's not a big deal if building
something from the repository is slightly
On 03/22/2010 06:40 PM, Pekka Enberg wrote:
On Mon, Mar 22, 2010 at 6:16 PM, Avi Kivitya...@redhat.com wrote:
You simply kept ignoring me when I said that if something can be kept out
of the kernel without impacting performance, it should be. I don't want
emergency patches closing some
On 03/22/2010 04:47 PM, Ingo Molnar wrote:
If you are interested in the first-hand experience of the people who are
doing the perf work then here it is: by far the biggest reason for perf
success and perf usability is the integration of the user-space tooling
with the kernel-space bits, into a
On 03/22/2010 08:10 PM, Pekka Enberg wrote:
On Mon, Mar 22, 2010 at 8:04 PM, Avi Kivitya...@redhat.com wrote:
That said, pulling 400 KLOC of code into the kernel sounds really
excessive. Would we need all that if we just do native virtualization
and no actual emulation?
What is
On 03/22/2010 04:54 PM, Ingo Molnar wrote:
* Pekka Enbergpenb...@cs.helsinki.fi wrote:
Hi Avi,
On Mon, Mar 22, 2010 at 2:49 PM, Avi Kivitya...@redhat.com wrote:
Seems like perf is also split, with sysprof being developed outside the
kernel. ?Will you bring sysprof into the
On 03/22/2010 09:10 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/22/2010 06:32 PM, Ingo Molnar wrote:
So, what do you think creates code communities and keeps them alive?
Developers and code. And the wellbeing of developers are primarily
influenced by the
On 03/22/2010 09:20 PM, Joerg Roedel wrote:
Why doesnt it solve the bisectability problem? The kernel repo is supposed to
be bisectable so that problem would be solved.
Because Marcelo and Avi try to keep as close to upstream qemu as
possible. So the qemu repo is regularly merged in
On 03/22/2010 09:20 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by
Anthony. There's numerous ways that this can break:
I don't like it either. We have libvirt for enumerating guests.
Which has
On 03/22/2010 09:22 PM, Ingo Molnar wrote:
Transitive had a product that was using a KVM context to run their
binary translator which allowed them full access to the host
processes virtual address space range. In this case, there is no
kernel and there are no devices.
And your point is
On 03/22/2010 09:27 PM, Ingo Molnar wrote:
If your position basically boils down to, we can't trust userspace
and we can always trust the kernel, I want to eliminate any
userspace path, then I can't really help you out.
Why would you want to 'help me out'? I can tell a good solution
On 03/22/2010 10:06 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
On 03/22/2010 09:20 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by
Anthony. There's numerous ways that this can
On 03/22/2010 10:21 PM, Ingo Molnar wrote:
* Alexander Grafag...@suse.de wrote:
Furthermore, another negative effect is that many times features are
implemented not in their technically best way, but in a way to keep them
local to the project that originates them. This is done to keep
On 03/22/2010 10:29 PM, Ingo Molnar wrote:
* Avi Kivitya...@redhat.com wrote:
I think you didnt understand my point. I am talking about 'perf kvm top'
hanging if Qemu hangs.
Use non-blocking I/O, report that guest as dead. No point in profiling it,
it isn't making any progress.
On 03/22/2010 10:32 PM, Ingo Molnar wrote:
* Anthony Liguorianth...@codemonkey.ws wrote:
On 03/22/2010 02:22 PM, Ingo Molnar wrote:
Transitive had a product that was using a KVM context to run their
binary translator which allowed them full access to the host
processes virtual
On 03/22/2010 10:35 PM, Ingo Molnar wrote:
And your point is that such vcpus should be excluded from profiling just
because they fall outside the Qemu/libvirt umbrella?
That is a ridiculous position.
Non-guest vcpus will not be able to provide Linux-style symbols.
And why do
On 03/22/2010 10:46 PM, Ingo Molnar wrote:
You should instead read the long list of disadvantages above, invert them
and list then as advantages for the kernel-based vcpu enumeration
solution, apply common sense and go admit to yourself that indeed in this
situation a kernel provided
On 03/22/2010 11:04 PM, Chris Webb wrote:
Chris Webbch...@arachsys.com writes:
Okay. What I was driving at in describing these systems as 'already broken'
is that they will already lose data (in this sense) if they're run on bare
metal with normal commodity SATA disks with their 32MB
On 03/23/2010 06:01 AM, Xu, Dongxiao wrote:
Avi Kivity wrote:
On 03/18/2010 11:49 AM, Xu, Dongxiao wrote:
VMX: Support for coexistence of KVM and other hosted VMMs.
The following NOTE is picked up from Intel SDM 3B 27.3 chapter,
MANAGING VMCS REGIONS AND POINTERS
On 03/23/2010 10:33 AM, Xu, Dongxiao wrote:
Did you measure workloads that exit to userspace very often?
Also, what about future processors? My understanding is that the
manual recommends keeping things cached, the above description is for
sleep states.
I measured the performance by
On 03/23/2010 12:06 AM, Anthony Liguori wrote:
Having qemu enumerate guests one way or another is not a good idea
IMO since it is focused on one guest and doesn't have a system-wide
entity.
There always needs to be a system wide entity. There are two ways to
enumerate instances from that
On 03/23/2010 08:12 AM, Takuya Yoshikawa wrote:
Hi, does anybody knows about this?
Currently, dirty bitmap is updated by generic___set_le_bit().
I checked the git log and mail archives but could not find any
explanation why replacing set_bit() by generic___set_le_bit() is
safe.
IIRC
On 03/23/2010 11:31 AM, Jan Kiszka wrote:
Chris Wright wrote:
Please send in any agenda items you are interested in covering.
Yes, usability is a valid topic esp. if you promise to come w/ GUI patches.
- state and roadmap for upstream merge of in-kernel device models
(looks to
On 03/23/2010 03:00 AM, Badari Pulavarty wrote:
Forgot to CC: KVM list earlier
[RFC] vhost-blk implementation.eml
Subject:
[RFC] vhost-blk implementation
From:
Badari Pulavarty pbad...@us.ibm.com
Date:
Mon, 22 Mar 2010 17:34:06 -0700
To:
virtualizat...@lists.linux-foundation.org,
On 03/23/2010 04:50 AM, Badari Pulavarty wrote:
Anthony Liguori wrote:
On 03/22/2010 08:45 PM, Badari Pulavarty wrote:
Anthony Liguori wrote:
On 03/22/2010 08:00 PM, Badari Pulavarty wrote:
Forgot to CC: KVM list earlier
These virtio results are still with a 2.6.18 kernel with no aio,
On 03/22/2010 11:13 AM, Sheng Yang wrote:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 06108f3..f971b9b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1804,9 +1804,15 @@ static u64 construct_eptp(unsigned long root_hpa)
{
u64 eptp;
- /* TODO write
On 03/22/2010 12:29 PM, Jan Kiszka wrote:
A 16-bit TSS is only 44 bytes long. So make sure to test for the correct
size on task switch.
This should be stable material as well. I can provide a patch that
applies on .32 and .33, or what will be the procedure?
I'd like to drop the Cc:
On 03/23/2010 12:25 PM, Avi Kivity wrote:
This should be stable material as well. I can provide a patch that
applies on .32 and .33, or what will be the procedure?
I'd like to drop the Cc: stable and maintain stable queues explicitly
(in kvm-updates/2.6.3[23]). I'll fast-forward
On 03/19/2010 03:12 PM, Anthony Liguori wrote:
On 03/19/2010 07:58 AM, Paolo Bonzini wrote:
1) Change the default CPUID bits from 6/2/3 to 6/6/1, this passes the
Linux kernel check. But I am not sure if that would introduce
regressions, since some OSes apply quirks if they detect certain
On 03/17/2010 08:16 PM, Marcelo Tosatti wrote:
On Sun, Mar 14, 2010 at 10:22:52AM +0200, Avi Kivity wrote:
Direct maps are linear translations for a section of memory, used for
real mode or with large pages. As such, they are independent of the guest
levels.
Teach the mmu about
On 03/23/2010 12:50 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 03/23/2010 11:31 AM, Jan Kiszka wrote:
Chris Wright wrote:
Please send in any agenda items you are interested in covering.
Yes, usability is a valid topic esp. if you promise to come w/ GUI
patches
On 03/23/2010 12:51 PM, Avi Kivity wrote:
On 03/17/2010 08:16 PM, Marcelo Tosatti wrote:
On Sun, Mar 14, 2010 at 10:22:52AM +0200, Avi Kivity wrote:
Direct maps are linear translations for a section of memory, used for
real mode or with large pages. As such, they are independent of the
guest
On 03/23/2010 01:21 PM, Jan Kiszka wrote:
A 44-byte TSS has a limit of 43 (just like a 4GB segment has a limit of
0x), so there is an off-by-one here.
Right - you just found an (harmless) off-by-one in our legacy OS as well
(I blindly copied its limit).
It's a very
On 03/23/2010 01:13 PM, Jan Kiszka wrote:
The benefit would be that qemu-kvm.git would become a staging tree
instead of the master repository for kvm users. As an example, we
wouldn't have any bisectability problems. kvm features would need to be
written just once.
The last item
On 03/21/2010 01:08 PM, Gleb Natapov wrote:
Decode CMPXCHG8B destination operand in decoding stage. Fixes regression
introduced by If LOCK prefix is used dest arg should be memory commit.
This commit relies on dst operand be decoded at the beginning of an
instruction emulation.
Applied,
On 03/21/2010 04:58 PM, Gleb Natapov wrote:
When CMPXCHG8B is executed without LOCK prefix it is racy. Preserve this
behaviour in emulator too.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm
On 03/23/2010 01:25 PM, Jan Kiszka wrote:
From: Jan Kiszkajan.kis...@siemens.com
A 16-bit TSS is only 44 bytes long. So make sure to test for the correct
size on task switch.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this
On 03/23/2010 02:45 PM, Anthony Liguori wrote:
On 03/23/2010 04:52 AM, Avi Kivity wrote:
On 03/23/2010 11:31 AM, Jan Kiszka wrote:
Chris Wright wrote:
Please send in any agenda items you are interested in covering.
Yes, usability is a valid topic esp. if you promise to come w/ GUI
patches
On 03/23/2010 04:55 PM, Badari Pulavarty wrote:
This should be done asynchronously. That is likely the cause of
write performance degradation. For reads, readahead means that that
you're async anyway, but writes/syncs are still synchronous.
I am not sure what you mean by async here. Even if
On 03/23/2010 08:21 PM, Joerg Roedel wrote:
On Tue, Mar 23, 2010 at 06:39:58PM +0200, Avi Kivity wrote:
On 03/23/2010 04:06 PM, Joerg Roedel wrote:
And this system wide entity is the kvm module. It creates instances of
'struct kvm' and destroys them. I see no problem if we just
On 03/19/2010 01:12 AM, Zachary Amsden wrote:
On 03/18/2010 01:50 AM, Thomas Mueller wrote:
hi
following situation:
- 1 physical host, 1x windows 2008 guest = clock ok
- 1 physical host, 2x windows 2008 guest = clock drifts
seen with kvm-0.11 and kvm-0.12.3 and kernel 2.6.32.
not tried the
On 03/24/2010 07:09 AM, Andi Kleen wrote:
Joerg Roedelj...@8bytes.org writes:
Sidenote: I really think we should come to a conclusion about the
concept. KVM integration into perf is very useful feature to
analyze virtualization workloads.
Agreed. I especially
On 03/24/2010 09:38 AM, Andi Kleen wrote:
If you're profiling a single guest it makes more sense to do this from
inside the guest - you can profile userspace as well as the kernel.
I'm interested in debugging the guest without guest cooperation.
In many cases qemu's new gdb stub works
On 03/23/2010 07:15 PM, Marcelo Tosatti wrote:
Document that KVM_REQ_PENDING_TIMER is implicitly used during guest
entry.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
On 03/19/2010 11:58 AM, Xiao Guangrong wrote:
- Check reserved bits only if CR4.PAE=1 or CR4.PSE=1 when guest #PF occurs
- Fix a typo in reset_rsvds_bits_mask()
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the
On 03/22/2010 12:49 PM, Alexander Graf wrote:
When we fail to create a VCPU we have no way to tell our callers that something
failed. So the caller happily uses a completely broken state.
This code should become deprecated in the process of converting qemu-kvm to
qemu anyways, so let's not care
On 03/23/2010 06:53 PM, Marcelo Tosatti wrote:
See individual patches for details.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On 03/23/2010 06:37 PM, Marcelo Tosatti wrote:
See individual patches for details.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
On 03/24/2010 01:59 PM, Joerg Roedel wrote:
On Wed, Mar 24, 2010 at 06:57:47AM +0200, Avi Kivity wrote:
On 03/23/2010 08:21 PM, Joerg Roedel wrote:
This enumeration is a very small and non-intrusive feature. Making it
aware of namespaces is easy too.
It's easier (and safer
On 03/17/2010 10:12 PM, Michael Tokarev wrote:
When run with -smp 17 or greather, kvm
fails like this:
$ kvm -smp 17
kvm_create_vcpu: Invalid argument
kvm_setup_mce FAILED: Invalid argument
KVM_SET_LAPIC failed
Segmentation fault
$ _
In qemu-kvm.c, the kvm_create_vcpu() routine
(which is used
On 03/17/2010 11:14 PM, André Weidemann wrote:
qemu-system-x86_64 -cpu core2duo -vga cirrus -boot order=ndc -vnc
192.168.3.42:2 -k de -smp 4,cores=4 -drive
file=/vmware/Windows7Test_600G.img,if=ide,index=0,cache=writeback -m
1024 -net nic,model=e1000,macaddr=DE:AD:BE:EF:12:3A -net
On 03/19/2010 12:46 AM, Fede wrote:
I'm currently working to enable vga passthrough in kvm.
assigned_dev_iomem_map: e_phys=1000 r_virt=0x7fa64af0e000 type=0
len=0200 region_num=3
kvm_register_phys_mem:580 memory: gpa: 1000, size: 200, uaddr:
7fa64af0e000, slot: 7,flags: 0
On 03/17/2010 03:04 PM, Michael S. Tsirkin wrote:
This is port of vhost v6 patch set I posted previously to qemu-kvm, for
those that want to get good performance out of it :) This patchset needs
to be applied when qemu.git one gets merged, this includes irqchip
support.
Ping me when this
On 03/24/2010 02:50 PM, Joerg Roedel wrote:
You can always provide the kernel and module paths as command line
parameters. It just won't be transparently usable, but if you're using
qemu from the command line, presumably you can live with that.
I don't want the tool for myself only. A
On 03/24/2010 03:46 PM, Joerg Roedel wrote:
On Wed, Mar 24, 2010 at 03:05:02PM +0200, Avi Kivity wrote:
On 03/24/2010 02:50 PM, Joerg Roedel wrote:
I don't want the tool for myself only. A typical perf user expects that
it works transparent.
A typical kvm user uses
On 03/24/2010 03:53 PM, Alexander Graf wrote:
Someone needs to know about the new guest to fetch its symbols. Or do
you want that part in the kernel too?
How about we add a virtio guest file system access device? The guest
would then expose its own file system using that device.
On
On 03/24/2010 04:24 PM, Alexander Graf wrote:
Avi Kivity wrote:
On 03/24/2010 03:53 PM, Alexander Graf wrote:
Someone needs to know about the new guest to fetch its symbols. Or do
you want that part in the kernel too?
How about we add a virtio guest file system
On 03/24/2010 05:01 PM, Joerg Roedel wrote:
But when I weigh the benefit of truly transparent system-wide perf
integration for users who don't use libvirt but do use perf, versus
the cost of transforming kvm from a single-process API to a
system-wide API with all the complications that I've
On 03/08/2010 08:40 AM, Hao, Xudong wrote:
Hi, all,
This is KVM biweekly test result against kvm.git:
647e9ec3b543ea04d49a7323dfe0070682ed8465 and qemu-kvm.git:
7811d4e8ec057d25db68f900be1f09a142faca49.
In the last month, KVM testing was blocked by one qemu-img issue and two qemu
build
On 03/24/2010 05:37 PM, Joerg Roedel wrote:
No it can't. With sVirt every single VM has a custom security label and
the policy only allows it access to disks / files with a matching label,
and prevents it attacking any other VMs or processes on the host. THis
confines the scope of any exploit
On 03/24/2010 05:46 PM, Joerg Roedel wrote:
On Wed, Mar 24, 2010 at 05:12:55PM +0200, Avi Kivity wrote:
On 03/24/2010 05:01 PM, Joerg Roedel wrote:
$ cd /sys/kvm/guest0
$ ls -l
-r 1 root root 0 2009-08-17 12:05 name
dr-x-- 1 root root 0 2009-08-17 12:05 fs
$ cat name
On 03/24/2010 05:50 PM, Joerg Roedel wrote:
On Wed, Mar 24, 2010 at 05:43:31PM +0200, Avi Kivity wrote:
On 03/24/2010 05:37 PM, Joerg Roedel wrote:
Even better. So a guest which breaks out can't even access its own
/sys/kvm/ directory. Perfect, it doesn't need that access anyway
On 03/24/2010 05:59 PM, Joerg Roedel wrote:
I am not tied to /sys/kvm. We could also use /proc/pid/kvm/ for
example. This would keep anything in the process space (except for the
global list of VMs which we should have anyway).
How about ~/.qemu/guests/$pid?
That makes it
On 03/24/2010 06:03 PM, Peter Zijlstra wrote:
On Wed, 2010-03-24 at 16:01 +0100, Joerg Roedel wrote:
What I meant was: perf-kernel puts the guest-name into every sample and
perf-userspace accesses /sys/kvm/guest_name/fs/ later to resolve the
symbols. I leave the question of how the
On 03/24/2010 06:17 PM, Joerg Roedel wrote:
On Wed, Mar 24, 2010 at 05:52:54PM +0200, Avi Kivity wrote:
On 03/24/2010 05:50 PM, Joerg Roedel wrote:
If we go the /proc/pid/kvm way then the directory should probably
inherit the label from /proc/pid/?
That's a security policy
On 03/24/2010 06:20 PM, André Weidemann wrote:
Does this happen with a guest installed on kvm, or just with the guest
that (guessing from the name) was imported from vmware?
I booted the VM via PXE into an Ubuntu Live CD image. I only added the
Windows disk image, so I could copy the
On 03/24/2010 06:31 PM, Joerg Roedel wrote:
On Wed, Mar 24, 2010 at 06:20:38PM +0200, Avi Kivity wrote:
On 03/24/2010 06:17 PM, Joerg Roedel wrote:
But is this not only one entity more for
sVirt to handle? I would leave that decision to the sVirt developers.
Does attaching the same
On 03/24/2010 06:40 PM, Joerg Roedel wrote:
Looks trivial to find a guest, less so with enumerating (still doable).
Not so trival and even more likely to break. Even it perf has the pid of
the process and wants to find the directory it has to do:
1. Get the uid of the process
2. Find
On 03/24/2010 06:45 PM, Joerg Roedel wrote:
That's just what I want to do. Leave it in userspace and then they can
deal with it without telling us about it.
They can't do that with a directory in /proc?
I don't know.
--
error compiling committee.c: too many arguments to
On 03/24/2010 06:47 PM, Avi Kivity wrote:
It's true. If the kernel provides something, there are fewer things
that can break. But if your system is so broken that you can't
resolve uids, fix that before running perf. Must we design perf for
that case?
After all, 'ls -l' will break under
On 03/24/2010 07:47 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Mar 24, 2010 at 06:09:30PM +0200, Avi Kivity escreveu:
Doesn't perf already has a dependency on naming conventions for finding
debug information?
It looks at several places, from most symbol rich (/usr/lib/debug/, aka
On 03/24/2010 10:05 PM, Christoph Hellwig wrote:
On Tue, Mar 23, 2010 at 12:03:14PM +0200, Avi Kivity wrote:
I also think it should be done at the bio layer. File I/O is going to
be slower, if we do vhost-blk we should concentrate on maximum
performance. The block layer also exposes more
On 03/24/2010 10:22 PM, Badari Pulavarty wrote:
Which caching mode is this? I assume data=writeback, because otherwise
you'd be doing synchronous I/O directly from the handler.
Yes. This is with default (writeback) cache model. As mentioned
earlier, readhead is helping here
and most cases,
On 03/25/2010 08:08 AM, Cam Macdonell wrote:
Support an inter-vm shared memory device that maps a shared-memory object
as a PCI device in the guest. This patch also supports interrupts between
guest by communicating over a unix domain socket. This patch applies to the
qemu-kvm repository.
On 03/25/2010 11:26 AM, Markus Armbruster wrote:
Avi Kivitya...@redhat.com writes:
Please put the spec somewhere publicly accessible with a permanent
URL. I suggest a new qemu.git directory specs/. It's more important
than the code IMO.
What about docs/? It already exists.
On 03/25/2010 11:15 AM, Michael S. Tsirkin wrote:
- Why are you using 32 bit long memory accesses for interrupts?
16 bit IO eould be enough and it's faster. This what virtio-pci does.
Why is 16 bit io faster?
--
error compiling committee.c: too many arguments to function
--
To
On 03/25/2010 08:09 AM, Cam Macdonell wrote:
This patch adds a driver for my shared memory PCI device using the uio_pci
interface. The driver has three memory regions. The first memory region is for
device registers for sending interrupts. The second BAR is for receiving MSI-X
interrupts and
Signed-off-by: Avi Kivity a...@redhat.com
---
Documentation/kvm/api.txt | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index d170cb4..22af28a 100644
--- a/Documentation/kvm
Signed-off-by: Avi Kivity a...@redhat.com
---
Documentation/kvm/api.txt | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index 22af28a..8f45099 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation
Avi Kivity (2):
KVM: Document KVM_SET_USER_MEMORY_REGION
KVM: Document KVM_SET_TSS_ADDR
Documentation/kvm/api.txt | 59 +
1 files changed, 59 insertions(+), 0 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe kvm
1 - 100 of 16034 matches
Mail list logo
