On Sun, Sep 12, 2010 at 05:59:45PM +0200, Avi Kivity wrote: > On 09/12/2010 05:31 PM, Anthony Liguori wrote: > >On 09/12/2010 01:11 AM, Avi Kivity wrote: > >> On 09/10/2010 10:48 PM, Anthony Liguori wrote: > >>>>I agree, is there any reason not to enable compiling less > >>>>into the binary? > >>>>There are folks interested in eliminating as much as > >>>>possible to reduce > >>>>the attack surface and auditing requirements, for example. > >>> > >>>It's not a bad idea, it's just that what > >>>--disable-cpu-emulation does is evil. Being that I wrote the > >>>implementation, I'm quite confident in declare it as such :-) > >>> > >> > >>Oh, I thought you were against the idea in itself for some reason. > >> > >>I'll patch it for 0.13, but any ideas on how it should be rework > >>for master? > > > >Glauber's old Accel interface was close to the right approach. We > >need to abstract the exec.c interfaces to use a function pointer > >table and have a TCG and KVM implementation. The function pointer > >tables can then be registered by a module_init() and we can simply > >not include the kvm or TCG files are build time to disable the > >functionality. > > Yes, I remember it now. > > Glauber, can you bring those patches back from the land of the dead? I could, but I myself was not entirely sure about the correct approach in terms of granularity. The first version was too fine grained, since I was hooking into every possible kqemu operation, (the goal at the time was to take _that_ out, not tcg), and then second version got too coarse, with we having to rewrite whole parts of memory. Now that kqemu is gone, it surely gets easier... -- 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
