Author Archives: Stephen Spector

About Stephen Spector

Stephen Spector is the Program Manager for Xen.org responsible for the Xen.org website, events (Xen Summits), mailing lists, and all things non-technical related to Xen.org.

[RFC] Handling of number of cores the guest sees

From Andre Przywara:

while experimenting with guest NUMA configurations I realized that Xen injects the host’s core number into each guest.
I believe this behavior is wrong, the number of cores should somehow be dependent from the number of VCPUs.
Currently a CPUID decoding tool of mine gives me the following output for a 4 VCPU guest:
————
HTT: 1, CmpLegacy: 1, LogicalProcessorCount: 24 AMD decoding:
NC: 23, ApicIdCoreIdSize: 16
24 cores   (legacy method)
24/16 cores (extended method)
————
(This is on a 12-core host CPU).
Applying my previous patch reduces the 24 to 12, but that still does not match the 4 VCPUs seen.
For proper NUMA functionality we need more sane values here, it seems that at least Linux does not care about the strange numbers as long as NUMA is not used. When a SRAT table is found, the guest kernel panics in the scheduler’s rebalancer with those bogus numbers.

How shall we solve this issue? I see several ways:

1. Always inject one core per processor. SMP guests are then n-way, the CPUID setup is trivial and works well. But we may run into licensing issues, as some software (MS Windows comes to mind) is limited by the number of processors, but not by the number of cores.

2. Inject exactly the same number of cores as there are VCPUs. This could lead to potentially strange core numbers, but software should cope with this (as there are 3-core, 6-core and 12-cores processors).
This would lead to problems with a NUMA setup, though.

3. Let the user specify the number of cores in the config file. Needs user interaction and can lead to problems if it somehow conflicts the number of VCPUs. But would be nice to have as an additional tuning parameter. I could implement this.

4. Implement solution 2), but tune the behavior if guest NUMA is enabled. We could make sure that the number of cores is not bigger than the number of VCPUs on one NUMA node.

What approach shall I use? Are there other concerns regarding the CPUID’s readout of the nubmer of cores?

Project ThreeEyes – Proposal Received

As I mentioned a few weeks back, Project ThreeEyes is the new effort to completely revamp the existing Xen.org website. I have opened the process up for web development companies to bid on and have received the first bid from Accelerator Enterprise Technologies. Here are the main highlights of their proposal:

***********

We firmly believe it’s time for Xen.org to upgrade. We hereby propose a new system wherein Xen.org is reshaped as the centralized portal for the various scattered resources by incorporating the following:

1) LAMP stacks installed on top of the very latest Xen software running on a server supplied by Citrix.

2) Drupal as core CMS and feed aggregator. Drupal will channel all Xen-related info through Xen.org rather than forcing the user to look all over for it.

3) phpBB forum for community support. The mailing list will remain available for traditionalists, but forums are more effective in a larger community because everyone doesn’t get everyone else’s mail. Ideally, the forum is integrated with the mailing list.

4) OpenGrok to publish cross-referenced source code at Xen.org at frequent, regular intervals.

5) All content routed through Xen.org and globally searchable using Google Custom Search. The Google search engine will be kept apprised of content changes through automated sitemap generation.

6) Existing developer resources (source control, Bugzilla, LXR, mailing lists) remain as-is so the core development team can continue without interruption.

We recommend these strategies and technologies because of their open-source nature, best-in-class quality, robust support communities and suitability to the needs of the Xen site.

***********

If you are interested in seeing the complete proposal then email me for a copy. I also plan to begin discussing this project on the xen-community mailing list to allow for community input. I look forward to having a great new Xen.org site with community buy-in and support in creating the final deliverable.

Why Xen? Brochure Available

As part of the new Why Xen? document series, I am announcing the Why Xen? brochure for community use: here. Also available are the following:

As is standard, if you have any feedback or changes please let me know. I am also looking to get translated copies of these documents to reach a wider audience.

Re-License LIBXC under LGPL

From Ian Campbell:

As previously discussed we would like to relicense libxc under the LGPL.

http://blog.xenproject.org/index.php/2010/07/26/xen-org-source-code-license-change-request/
http://lists.xensource.com/archives/html/xen-devel/2010-07/msg01378.html

We have now managed to track down all but one of the necessary contributors in order to make this change and all have given their OK to the change.

Due to the missing contributor (who we do not expect we will be able to find) we have taken the decision to remove the xc_ptrace functionality. It is currently unused, the last remaining user having been replaced by gdbsx. Should this code be required in the future it can be recovered from mercurial history and reinstated as a separate library.

There are two patches currently in review on xen-devel for this final change.