* oerg Roedel <joro@xxxxxxxxxx> wrote: > On Fri, Mar 19, 2010 at 09:21:22AM +0100, Ingo Molnar wrote: > > Unfortunately, in a previous thread the Qemu maintainer has indicated that he > > will essentially NAK any attempt to enhance Qemu to provide an easily > > discoverable, self-contained, transparent guest mount on the host side. > > > > No technical justification was given for that NAK, despite my repeated > > requests to particulate the exact security problems that such an approach > > would cause. > > > > If that NAK does not stand in that form then i'd like to know about it - it > > makes no sense for us to try to code up a solution against a standing > > maintainer NAK ... > > I still think it is the best and most generic way to let the guest do the > symbol resolution. [...] Not really. > [...] This has several advantages: > > 1. The guest knows best about its symbol space. So this would be > extensible to other guest operating systems. A brave > developer may even implement symbol passing for Windows or > the BSDs ;-) Having access to the actual executable files that include the symbols achieves precisely that - with the additional robustness that all this functionality is concentrated into the host, while the guest side is kept minimal (and transparent). > 2. The guest can decide for its own if it want to pass this > inforamtion to the host-perf. No security issues at all. It can decide whether it exposes the files. Nor are there any "security issues" to begin with. > 3. The guest can also pass us the call-chain and we don't need > to care about complicated of fetching from the guest > ourself. You need to be aware of the fact that symbol resolution is a separate step from call chain generation. I.e. call-chains are a (entirely) separate issue, and could reasonably be done in the guest or in the host. It has no bearing on this symbol resolution question. > 4. This way extensible to nested virtualization too. Nested virtualization is actually already taken care of by the filesystem solution via an existing method called 'subdirectories'. If the guest offers sub-guests then those symbols will be exposed in a similar way via its own 'guest files' directory hierarchy. I.e. if we have 'Guest-2' nested inside 'the 'Guest-Fedora-1' instance, we get: /guests/ /guests/Guest-Fedora-1/etc/ /guests/Guest-Fedora-1/usr/ we'd also have: /guests/Guest-Fedora-1/guests/Guest-2/ So this is taken care of automatically. I.e. none of the four 'advantages' listed here are actually advantages over my proposed solution, so your conclusion is subsequently flawed as well. > How we speak to the guest was already discussed in this thread. My personal > opinion is that going through qemu is an unnecessary step and we can solve > that more clever and transparent for perf. Meaning exactly what? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
