Prev: + tmpfs-fix-oops-on-remounts-with-mpol=default.patch added to -mm tree
Next: [PATCH 5/5] doc: add the documentation for mpol=local
From: Avi Kivity on 16 Mar 2010 08:30 On 03/16/2010 01:25 PM, Ingo Molnar wrote: > >> I haven't followed vmchannel closely, but I think it is. vmchannel is >> terminated in qemu on the host side, not in the host kernel. So perf would >> need to connect to qemu. >> > Hm, that sounds rather messy if we want to use it to basically expose kernel > functionality in a guest/host unified way. Is the qemu process discoverable in > some secure way? We know its pid. > Can we trust it? No choice, it contains the guest address space. > Is there some proper tooling available to do > it, or do we have to push it through 2-3 packages to get such a useful feature > done? > libvirt manages qemu processes, but I don't think this should go through libvirt. qemu can do this directly by opening a unix domain socket in a well-known place. > ( That is the general thought process how many cross-discipline useful > desktop/server features hit the bit bucket before having had any chance of > being vetted by users, and why Linux sucks so much when it comes to feature > integration and application usability. ) > You can't solve everything in the kernel, even with a well populated tools/. -- 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 16 Mar 2010 08:40 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/16/2010 01:25 PM, Ingo Molnar wrote: > > > >>I haven't followed vmchannel closely, but I think it is. vmchannel is > >>terminated in qemu on the host side, not in the host kernel. So perf would > >>need to connect to qemu. > >Hm, that sounds rather messy if we want to use it to basically expose kernel > >functionality in a guest/host unified way. Is the qemu process discoverable in > >some secure way? > > We know its pid. How do i get a list of all 'guest instance PIDs', and what is the way to talk to Qemu? > > Can we trust it? > > No choice, it contains the guest address space. I mean, i can trust a kernel service and i can trust /proc/kallsyms. Can perf trust a random process claiming to be Qemu? What's the trust mechanism here? > > Is there some proper tooling available to do it, or do we have to push it > > through 2-3 packages to get such a useful feature done? > > libvirt manages qemu processes, but I don't think this should go through > libvirt. qemu can do this directly by opening a unix domain socket in a > well-known place. So Qemu has never run into such problems before? ( Sounds weird - i think Qemu configuration itself should be done via a unix domain socket driven configuration protocol as well. ) > >( That is the general thought process how many cross-discipline useful > > desktop/server features hit the bit bucket before having had any chance of > > being vetted by users, and why Linux sucks so much when it comes to feature > > integration and application usability. ) > > You can't solve everything in the kernel, even with a well populated tools/. Certainly not, but this is a technical problem in the kernel's domain, so it's a fair (and natural) expectation to be able to solve this within the kernel project. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 16 Mar 2010 08:50 On 03/16/2010 02:29 PM, Ingo Molnar wrote: > * Avi Kivity<avi(a)redhat.com> wrote: > > >> On 03/16/2010 01:25 PM, Ingo Molnar wrote: >> >>> >>>> I haven't followed vmchannel closely, but I think it is. vmchannel is >>>> terminated in qemu on the host side, not in the host kernel. So perf would >>>> need to connect to qemu. >>>> >>> Hm, that sounds rather messy if we want to use it to basically expose kernel >>> functionality in a guest/host unified way. Is the qemu process discoverable in >>> some secure way? >>> >> We know its pid. >> > How do i get a list of all 'guest instance PIDs', Libvirt manages all qemus, but this should be implemented independently of libvirt. > and what is the way to talk > to Qemu? > In general qemu exposes communication channels (such as the monitor) as tcp connections, unix-domain sockets, stdio, etc. It's very flexible. >>> Can we trust it? >>> >> No choice, it contains the guest address space. >> > I mean, i can trust a kernel service and i can trust /proc/kallsyms. > > Can perf trust a random process claiming to be Qemu? What's the trust > mechanism here? > Obviously you can't trust anything you get from a guest, no matter how you get it. How do you trust a userspace program's symbols? you don't. How do you get them? they're on a well-known location. >>> Is there some proper tooling available to do it, or do we have to push it >>> through 2-3 packages to get such a useful feature done? >>> >> libvirt manages qemu processes, but I don't think this should go through >> libvirt. qemu can do this directly by opening a unix domain socket in a >> well-known place. >> > So Qemu has never run into such problems before? > > ( Sounds weird - i think Qemu configuration itself should be done via a > unix domain socket driven configuration protocol as well. ) > That's exactly what happens. You invoke qemu with -monitor unix:blah,server (or -qmp for a machine-readable format) and have your management application connect to that. You can redirect guest serial ports, console, parallel port, etc. to unix-domain or tcp sockets. vmchannel is an extension of that mechanism. >>> ( That is the general thought process how many cross-discipline useful >>> desktop/server features hit the bit bucket before having had any chance of >>> being vetted by users, and why Linux sucks so much when it comes to feature >>> integration and application usability. ) >>> >> You can't solve everything in the kernel, even with a well populated tools/. >> > Certainly not, but this is a technical problem in the kernel's domain, so it's > a fair (and natural) expectation to be able to solve this within the kernel > project. > Someone writing perf-gui outside the kernel would have the same problems, no? -- 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 16 Mar 2010 09:10 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/16/2010 02:29 PM, Ingo Molnar wrote: > > I mean, i can trust a kernel service and i can trust /proc/kallsyms. > > > > Can perf trust a random process claiming to be Qemu? What's the trust > > mechanism here? > > Obviously you can't trust anything you get from a guest, no matter how you > get it. I'm not talking about the symbol strings and addresses, and the object contents for allocation (or debuginfo). I'm talking about the basic protocol of establishing which guest is which. I.e. we really want to be able users to: 1) have it all working with a single guest, without having to specify 'which' guest (qemu PID) to work with. That is the dominant usecase both for developers and for a fair portion of testers. 2) Have some reasonable symbolic identification for guests. For example a usable approach would be to have 'perf kvm list', which would list all currently active guests: $ perf kvm list [1] Fedora [2] OpenSuse [3] Windows-XP [4] Windows-7 And from that point on 'perf kvm -g OpenSuse record' would do the obvious thing. Users will be able to just use the 'OpenSuse' symbolic name for that guest, even if the guest got restarted and switched its main PID. Any such facility needs trusted enumeration and a protocol where i can trust that the information i got is authorative. (I.e. 'OpenSuse' truly matches to the OpenSuse session - not to some local user starting up a Qemu instance that claims to be 'OpenSuse'.) Is such a scheme possible/available? I suspect all the KVM configuration tools (i havent used them in some time - gui and command-line tools alike) use similar methods to ease guest management? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 16 Mar 2010 09:20
On 03/16/2010 03:08 PM, Ingo Molnar wrote: > >>> I mean, i can trust a kernel service and i can trust /proc/kallsyms. >>> >>> Can perf trust a random process claiming to be Qemu? What's the trust >>> mechanism here? >>> >> Obviously you can't trust anything you get from a guest, no matter how you >> get it. >> > I'm not talking about the symbol strings and addresses, and the object > contents for allocation (or debuginfo). I'm talking about the basic protocol > of establishing which guest is which. > There is none. So far, qemu only dealt with managing just its own guest, and left all multiple guest management to higher levels up the stack (like libvirt). > I.e. we really want to be able users to: > > 1) have it all working with a single guest, without having to specify 'which' > guest (qemu PID) to work with. That is the dominant usecase both for > developers and for a fair portion of testers. > That's reasonable if we can get it working simply. > 2) Have some reasonable symbolic identification for guests. For example a > usable approach would be to have 'perf kvm list', which would list all > currently active guests: > > $ perf kvm list > [1] Fedora > [2] OpenSuse > [3] Windows-XP > [4] Windows-7 > > And from that point on 'perf kvm -g OpenSuse record' would do the obvious > thing. Users will be able to just use the 'OpenSuse' symbolic name for > that guest, even if the guest got restarted and switched its main PID. > > Any such facility needs trusted enumeration and a protocol where i can trust > that the information i got is authorative. (I.e. 'OpenSuse' truly matches to > the OpenSuse session - not to some local user starting up a Qemu instance that > claims to be 'OpenSuse'.) > > Is such a scheme possible/available? I suspect all the KVM configuration tools > (i havent used them in some time - gui and command-line tools alike) use > similar methods to ease guest management? > You can do that through libvirt, but that only works for guests started through libvirt. libvirt provides command-line tools to list and manage guests (for example autostarting them on startup), and tools built on top of libvirt can manage guests graphically. Looks like we have a layer inversion here. Maybe we need a plugin system - libvirt drops a .so into perf that teaches it how to list guests and get their symbols. -- 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |