Group Details Private

Xen Guru

Member List
  • RE: More than 64 vCPU on Debian11 VM and AMD EPYC

    @alexredston Hey, sorry I'm a little bit late here. So, with regard of VCPUs - there's a hardcoded limit of 128 actually in XEN hypervisor. Moreover XEN toolstack (when creating a guest) will check that guest VCPU limit is below physical CPUs available on the platform.
    Bypassing the VCPU 128 limit will require some rather important adjustements in XEN Hypervisor (basically the restrictions go with IOREQ server from QEMU and how LAPIC id are affected in XEN). So with the next XEN version this limit could potentially be increased (there's an ongoing work on this).

    The things you also probably would like to know about this VCPUs limit

    • not all of the guests can handle this VCPUs number (e.g. Windows will certainely crash)
    • when you gives a VM such a big VCPU number (basically more than 32) the VM can potentially provoke the DoS on the whole platform (this is related how some routines are "serialized" in XEN Hypervisor). So, when you do this - be aware that if your guest is broken, pawned, whatever... your whole platform can potentially become unresponsive.
    posted in Compute
  • RE: Change CPU Information

    Windows isn't going to be tricked into being happy about the CPU just by changing the reported model. It cross-checks real features, and you simply can't fake those up.

    There is no ability in XenServer/XCP-ng to configure this, and I have no intention to offer people the ability to shoot themselves in the foot like this.

    posted in Compute
  • RE: Xen 4.17 on XCP-ng 8.3!

    @Andrew said in Xen 4.17 on XCP-ng 8.3!:

    xtf HARD system freeze at test-hvm64-xsa-304. (only XCP hard lockup I have seen)
    xtf With ept=no-exec-sp, all tests SKIP/SUCCESS.

    XSA-304 is https://www.intel.com/content/www/us/en/developer/articles/troubleshooting/software-security-guidance/technical-documentation/machine-check-error-avoidance-page-size-change.html

    It's guest exploitable, and locks up the CPU so hard it doesn't even reset properly. It's also very expensive to work around, hence why it's not mitigated by default.

    posted in News
  • RE: Cannot start VM to which a sata controller and pci nvme is passed through to.

    @RAG67958472
    Thank you!

    This seems to be a bug. On some level when mapping NVMe device MMIO frame ef004 (BAR 4) it reuse the same guest frame where SATA device MMIO frame ef138 (BAR 1) is allready mapped. 😬 This is failing so the domain is stopped by XEN.

    I have no idea what part of code is responsible of reusing the same guest frame (gfn) for this mappings (probably in toolstack/QEMU,....).

    So at first it will be usefull have whole XEN traces from domU start (If I understand correctly you have XEN start in your traces and also the bug traces from 2 times you tried to launch the domU). Are these the only traces when you launch domU?

    The second thing - it would be nice to start XEN in debug mode (normally you have XEN image builded with debug traces activated) Can you please start this image and provide these traces.

    I will talk to XEN maintainers to see if the problem was allready reported by users. (The code wich stop the domain didn't change in most recent XEN, but the issue is probably situated in upper layers)

    It would be also very usefull to see if the problem is the same with pvh and hvm guests.

    posted in XCP-ng
  • RE: Cannot start VM to which a sata controller and pci nvme is passed through to.

    @RAG67958472
    Hmmm, seems to be a bug. There's someting special about machine frame ef004. I suppose it's a MMIO address (PCI bar?). Can you please provide an output of the whole xen log from the beggining with xl dmesg and also a pci conf space dump lspci -vvv ?
    What is weird you can passthrough the both devices individually.

    posted in XCP-ng