Description of problem:
tuned realtime-virtual-host profile adds tuned_params to GRUB cmdline for
installed kernels. When the profile is enabled several parameters are
added to configure the system for low latency. skew_tick=1 is one of them.

skew_tick=1 is the first parameter that gets concatenated at the end of
the current cmdline. However, a space is missing before it, so the
resulting cmdline ends up with something like the following

$ cat /proc/cmdline
BOOT_IMAGE=(hd0,msdos3)/vmlinuz-4.18.0-68.rt9.123.el8.x86_64 root=UUID=7f8ade5a-f325-404a-a6ea-8fd9ffc1affb ro crashkernel=auto rhgb quiet console=ttyS0,115200skew_tick=1 isolcpus=5,7-11 intel_pstate=disable nosoftlockup nohz=on nohz_full=5,7-11 rcu_nocbs=5,7-11

In a case like this skew_tick=1 is not correctly parsed by the early boot
stages of the kernel and the feature is not enabled (potentially
introducing latency spikes at runtime).

Version-Release number of selected component (if applicable):
2.10.0-14.el8

How reproducible:
Always after a new kernel is installed and profile (re-)enabled.

Steps to Reproduce:
1. Install a kernel-rt package
2. Enable realtime-virtual-host profile
3. Reboot
4. Check cmdline (cat /proc/cmdline)

Actual results:
Verify that a space is missing before skew_tick=1 parameter.

Expected results:
A space should be present before skew_tick=1 (and feature correctly enabled).

Additional info:
Checking that the skew_tick feature is enabled can be further done by tracing
an idle system for a few seconds and checking that tick is slightly skewed on
the CPUs.