XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    XCP on intel i9 12th or 13th generation

    Scheduled Pinned Locked Moved Compute
    5 Posts 2 Posters 3.0k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • cbaguzmanC Offline
      cbaguzman
      last edited by

      Hello everyone.

      I thing buy a new CPU for use with xcp-ng, but I have a doubts about how XCP works with Hybrid CPUs (P-Cores and E-Cores) .

      Ej. xcp use all Cores or only P-Cores? How xcp works with the VMs and P-Cores and E-Cores

      How xcp works with the VMs and P-Core and E-Core?

      someone know about it?

      Thanks Every One.

      1 Reply Last reply Reply Quote 0
      • olivierlambertO Offline
        olivierlambert Vates 🪐 Co-Founder CEO
        last edited by olivierlambert

        Hi,

        After a discussion with a Xen dev, the potential outcome isn't great. Due to their design, it seems impossible to virtualize those CPUs correctly with Xen. At best, you might have something that could barely work.

        If you want to test it, go ahead, but there's 0 guarantee you could do anything with it.

        edit: if you can disable all E cores, that might work, what's broken is the hybrid mode

        cbaguzmanC 1 Reply Last reply Reply Quote 0
        • olivierlambertO Offline
          olivierlambert Vates 🪐 Co-Founder CEO
          last edited by

          Read that if you want to see how bad Intel was a doing their CPU design: https://github.com/intelxed/xed/commit/7561f549d787edc55949b671dee2255a8435741a

          0 mjcharne committed to intelxed/xed
          ud0 length fix
          
            * Core and Atom designs disagree on UD0 length. UD0 is nominally
              0F.FF, legacy map 1, opcode 0xff. The disagreement is over the
              MODRM byte and subsequent optional bytes (SIB, disp8/32).
          
            * The design teams refuse to compromise and pick one length as they
              see any change as more work for no beneit.  In this case, they do
              not see value in consistently implementing the x86 ISA.
          
            * History: P6 (pentium pro) and the original Atom Bonnell implement
              UD0 without a MODRM byte. Just 0F.FF.  Pentium4 had an errata
              because it took a MODRM byte and potentially SIB and disp8/32
              bytes. Merom and subsequent parts followed P6's behavior. However
              Nehalem adopted the Pentium 4's behavior and that behavior
              continues in the Core products. Meanwhile all Atom products
              continue to decode UD0 as 2 bytes (0f.FF) without the MODRM.
          
               * The Intel SDM was updated in 2017 to indicate that only some
                 unspecified "older" processors treat UD0 as 2-bytes. In light
                 of the above history, that change can be viewed as superficial
                 or incorrect. The change only reflected the oscillation in
                 historical behavior of Core processors. It didn't account for
                 Atom's implementation..
          
               * AMD documents UD0 as 2-bytes without a MODRM.
          
            * Who cares?  Well if you have a UD0 near the end of a page and the
              subsquent page is inaccessible, you'll potentially get a
              segmentation violation on Core where as you won't on an Atom
              processor.
          
                * One could get differing page faults as well.
          
                * The behavior on 15-byte instructions also differs. Core will
                fetch the 16th byte before signaling a \#GP. Atom will signal a
                #GP after fetching the 15th byte and realizing it is not
                done. But that is a generic difference between current atom and
                core processors and is less relevant to the UD0 situation.
          
            * added code for UD0 to modrm table.
          
            * fixed the vex alias search for legacy map 1...
          
            * set_chip_modes() attempts to set a field MODE_SHORT_UD0 based on
              the specified chip. The default value is 0 corresponding to the
              "long" current Core behavior. So if you specify a chip, it'll try
              to do the right thing.
          
            * If you don't like specifying chips when you decode instructions,
              You can manually call "xed3_operand_set_mode_short_ud0(xedd, 1)"
              before decode (after initializing the xed_decoded_inst_t) to get
              the 2-byte UD0 behavior.
          
            * The following examples use xed3_set_generic_operand() in the xed
              command line tool.
          
              % obj/wkit/bin/xed  -set MODE_SHORT_UD0 1 -d 0F FF
              0FFF
              ICLASS:     UD0
              CATEGORY:   MISC
              EXTENSION:  BASE
              IFORM:      UD0
              ISA_SET:    PPRO_UD0_SHORT
              ATTRIBUTES: NOTSX
              SHORT:      ud0
          
              % obj/wkit/bin/xed  -set MODE_SHORT_UD0 0 -d 0F FF FE
              0FFFFE
              ICLASS:     UD0
              CATEGORY:   MISC
              EXTENSION:  BASE
              IFORM:      UD0_GPR32_GPR32
              ISA_SET:    PPRO_UD0_LONG
              ATTRIBUTES: NOTSX
              SHORT:      ud0 edi, esi
          
              Example showing 2-byte UD0 with a trailing FE byte:
          
              % obj/wkit/bin/xed  -set MODE_SHORT_UD0 1 -d 0F FF FE
              0FFFFE
              ICLASS:     UD0
              CATEGORY:   MISC
              EXTENSION:  BASE
              IFORM:      UD0
              ISA_SET:    PPRO_UD0_SHORT
              ATTRIBUTES: NOTSX
              SHORT:      ud0
              FE
              ERROR: BUFFER_TOO_SHORT Could not decode at offset: 0x0 len: 1 PC: 0x0: [FE]
          
              % obj/wkit/bin/xed  -set MODE_SHORT_UD0 0 -d 0F FF 90 90 90 90 90
              0FFF9090909090
              ICLASS:     UD0
              CATEGORY:   MISC
              EXTENSION:  BASE
              IFORM:      UD0_GPR32_MEMd
              ISA_SET:    PPRO_UD0_LONG
              ATTRIBUTES: NOTSX
              SHORT:      ud0 edx, dword ptr [eax-0x6f6f6f70]
          
              % obj/wkit/bin/xed  -set MODE_SHORT_UD0 1 -d 0F FF 90 90 90 90 90
              0FFF9090909090
              ICLASS:     UD0
              CATEGORY:   MISC
              EXTENSION:  BASE
              IFORM:      UD0
              ISA_SET:    PPRO_UD0_SHORT
              ATTRIBUTES: NOTSX
              SHORT:      ud0
              9090909090
              ICLASS:     NOP
              CATEGORY:   NOP
              EXTENSION:  BASE
              IFORM:      NOP_90
              ISA_SET:    I86
              ATTRIBUTES: NOP
              SHORT:      nop
              90909090
              ICLASS:     NOP
              CATEGORY:   NOP
              EXTENSION:  BASE
              IFORM:      NOP_90
              ISA_SET:    I86
              ATTRIBUTES: NOP
              SHORT:      nop
              <...snip...>
          
             * https://jira.devtools.intel.com/browse/SDE-2775
          1 Reply Last reply Reply Quote 0
          • cbaguzmanC Offline
            cbaguzman @olivierlambert
            last edited by cbaguzman

            @olivierlambert

            I'm going to buy a AMD Ryzen CPU.

            Thank @olivierlambert

            1 Reply Last reply Reply Quote 2
            • olivierlambertO Offline
              olivierlambert Vates 🪐 Co-Founder CEO
              last edited by

              Yes, frankly, go for AMD, they deserve it.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post