On 2012-08-14 16:44, Gleb Natapov wrote: > 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(). Yes, there might be more, but not under direct control of the guests, typically the workload that you don't have under the same control as your host processes. Will the stop_machine-free version hit the kernel together or shortly after your changes? I didn't follow that work. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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
