Announcement

Collapse
No announcement yet.

Intel UMIP KVM Support Ejected From Linux 4.15, Will Have To Wait To Linux 4.16

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel UMIP KVM Support Ejected From Linux 4.15, Will Have To Wait To Linux 4.16

    Phoronix: Intel UMIP KVM Support Ejected From Linux 4.15, Will Have To Wait To Linux 4.16

    Intel UMIP support landed in Linux 4.15 as part of the x86 updates. User-Mode Instruction Prevention is for preventing certain instructions from being executed outside of ring level zero and will be supported by future Intel CPUs. Support for UMIP within the KVM virtualization space though will have to wait until Linux 4.16...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    And yet 5-level Page Support is in 4.14 and causes my system not to boot when I enable it. Good job.

    Comment


    • #3
      Originally posted by Krejzi View Post
      And yet 5-level Page Support is in 4.14 and causes my system not to boot when I enable it. Good job.

      It will be supported by future Intel CPUs. Note: kernel with the option enabled can only be booted on machines that support the feature. See Documentation/x86/x86_64/5level-paging.txt for more info. Say N if unsure.
      I wonder which part of "kernel with the option enabled can only be booted on machines that support the feature" wasn't clear.



      https://github.com/torvalds/linux/bl.../Kconfig#L1404

      Comment


      • #4
        Originally posted by tpruzina View Post
        I wonder which part of "kernel with the option enabled can only be booted on machines that support the feature" wasn't clear.
        Did you just assume he does not have a SGI UV multi rack server cluster thing in his basement?

        Comment


        • #5
          Originally posted by starshipeleven View Post
          Did you just assume he does not have a SGI UV multi rack server cluster thing in his basement?
          Haven't even heard of any server CPUs that support thison X86 yet. The only way to make use of that kernel option is to use emulation in QEMU.

          Comment


          • #6
            Originally posted by tpruzina View Post




            I wonder which part of "kernel with the option enabled can only be booted on machines that support the feature" wasn't clear.



            https://github.com/torvalds/linux/bl.../Kconfig#L1404
            I'm pretty sure lot (all?) of the machines out there don't have all of the hardware whose drivers must be built into kernel, but they still boot with them enabled.

            Comment


            • #7
              Originally posted by Krejzi View Post

              I'm pretty sure lot (all?) of the machines out there don't have all of the hardware whose drivers must be built into kernel, but they still boot with them enabled.
              I guess the assumption is that people who build their own kernel know what they are doing, read help options or chose default action.
              You can build android kernel too if you want, it's (obviously) not gonna work on desktop x86 sysem. That said, they promised to add runtime detection at later point when the patches went in, for the time being they probably expect that people who build their own kernel can use their brain.

              Comment


              • #8
                So how would "linux-next" test a CPU feature for a CPU family (Cannonlake) that has not been introduced by Intel?

                Sounds like "the cart got ahead of the horse" by trying to get this feature into kernel mainline code ahead of the CPU release.

                Ok, Intel could probably test this internally and may have done so, but I understand the purpose of "linux-next" as giving prospective kernel code, and especially new features, broad exposure to a wide range of user test cases and platforms for TESTING before such code gets pulled by Linus, and sometimes that sort of exposure can cast a light on bugs, security flaws, and whatever else might be wrong with it. So I would agree with Linus on "unpulling" this one, especially given his previous experiences with untested or poorly tested code from his senior maintainers.

                Comment


                • #9
                  Originally posted by tpruzina View Post

                  I guess the assumption is that people who build their own kernel know what they are doing, read help options or chose default action.
                  You can build android kernel too if you want, it's (obviously) not gonna work on desktop x86 sysem. That said, they promised to add runtime detection at later point when the patches went in, for the time being they probably expect that people who build their own kernel can use their brain.
                  I really love that elitist feeling, it remind me of 60s with IBM and such

                  What's so wrong to do a runtime checking and explain things better when configuring a kernel before building it? Really, I don't get why even their GTK/QT versions are so scarce at explaining it. It's like they want to make difficult for others to learn something.

                  Oh, yes... RTFM. A bit more of active learning and progressive pedagogy wouldn't hurt Free Software, I'm really sure about that

                  Comment


                  • #10
                    Originally posted by timofonic View Post
                    What's so wrong to do a runtime checking and explain things better when configuring a kernel before building it?
                    The text in post https://www.phoronix.com/forums/foru...-to-linux-4-16

                    is shown in graphical kernel configuration tools or appears on screen if you press the "?" or "help" or whatever on the specific kernel option.

                    And by default this option is disabled, so people unaware of this option can ignore it and they won't be affected.

                    If people are compiling a kernel, and specifically enable features they don't understand, and don't even fucking read the 2-line feature description where it clearly states that the kernel won't boot if enabled on wrong hardware, then I'm more inclined to bash them, not the developers.

                    Comment

                    Working...
                    X