Group Details Private

Xen Guru

Member List
  • RE: Coral TPU PCI Passthrough

    @redakula Hello, unfortunately these patches are not in 4.17 Xen (and was never integrated in more recent Xen). So, to test it, you have to manually apply patches (normally should apply as is to 4.17) and rebuild your Xen.

    posted in Compute
  • RE: Issue after latest host update

    @RealTehreal Thank-you very much for that information. I'll follow up with Intel.

    In the short term, I'd recommend just using the old microcode.

    posted in XCP-ng
  • RE: Issue after latest host update

    @RealTehreal Sorry to keep adding to the list of diagnostics, but everything here will help. After you've tried the other options, could you try this:

    If the XTF testing shows any XTF test looping, use that single test, otherwise use your regular VM. Get one VM into the looping state. Check xl list to confirm that you've only got Domain-0 and the one other VM, and note it's domid (the "ID" column).

    In dom0, run xentrace to capture a system trace. It's looping so the dump file is going to be large, but it also means that you can CTRL-C as quickly as you can on the shell and it will be fine (a few hundred milliseconds of samples will almost certainly be enough).

    Anyway, run xentrace -D -e 0x0008f000 xentrace.dmp and then give me created xentrace.dmp file. If you're interested in what's in it, you can decode it using xenalyze -a xentrace.dmp |& less.

    Then, run xen-hvmctx $domid two or three times, and share the output of all.

    posted in XCP-ng
  • RE: Wyse 5070 VM won't booting after update bios 1.27

    @t-chamberlain In addition to the XTF testing, could you also please (with the bad microcode) try booting Xen with spec-ctrl=no-verw on the command line, and seeing whether that changes the behaviour of your regular VMs? Please capture xl dmesg from this run too.

    posted in Hardware
  • RE: Issue after latest host update

    @RealTehreal In addition to the XTF testing, could you also please try (with the bad microcode) booting Xen with spec-ctrl=no-verw on the command line, and seeing whether that changes the behaviour of your regular VMs? Please capture xl dmesg from this run too.

    posted in XCP-ng
  • RE: Issue after latest host update

    @RealTehreal It's an Intel issue, but while this is enough to show that there is an issue, it's not enough to figure out what is wrong.

    Sadly, a VM falling into a busy loop can be one of many things. It's clearly on the (v)BSP prior to starting (v)APs, hence why it's only ever a single CPU spinning.

    Can you switch to using the debug hypervisor (change the /boot/xen.gz symlink to point at the -d suffixed hypervisor), and then capture xl dmesg after trying to boot one VM. Depending on how broken things are, we might see some diagnostics.

    Could you also try running xtf as described here: https://xcp-ng.org/forum/post/57804 It's a long-shot, but if it does happen to stumble on the issue, then it will be orders of magnitude easier to debug than something misc broken in the middle of OVMF.

    posted in XCP-ng
  • 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