XCP on intel i9 12th or 13th generation

cbaguzman

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.

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

olivierlambert

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

cbaguzman

@olivierlambert

I'm going to buy a AMD Ryzen CPU.

Thank @olivierlambert

olivierlambert

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