On Tue, Aug 14, 2012 at 04:13:17PM +0200, Jan Kiszka wrote: > On 2012-08-14 16:07, Gleb Natapov wrote: > > On Tue, Aug 14, 2012 at 05:04:16PM +0300, Avi Kivity wrote: > >> On 08/14/2012 05:00 PM, Jan Kiszka wrote: > >> > >>>>> The host can prevent this by leaving disabling the guest pmu. But > >>>>> disabling jump labels for real-time kernels may be acceptable too. We > >>>>> can probably to it at run time by forcing the slow path at all times. > >>>> Yes, it is possible to add module option that will force slow path if > >>>> needed. > >>> > >>> Should I write a patch or will you? Having host-side stop_machine due to > >>> such common guest operations is indeed a no-go for RT. > >>> > >> > >> Note that an additional patch is needed for perf, otherwise the guest > >> (or a user, but that's less of a concern for realtime) can easily invoke > >> stop_machine by configuring and unconfiguring its pmu. > >> > >> > > Are we talking about malicious guests? Why not compile kernel with jump > > label disabled if this is serious concern? > > Because jump labels are still useful for other purposes (e.g. tracing) - > provided you don't use them while a critical operation is running. It's > cumbersome to require static configuration, specifically given that we > could easily control dynamically it at KVM level. > I am not against parameter. I just think you are fighting uphill battle. jump-label is not trace only thing. Their use expect to grow in kernel and those that this patchset adds are not the first that can be triggered by regular user. BTW there is work to make patching without calling stop_machine(). -- Gleb. -- 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
