similar to: [PATCH 1/6] xen: ACPI SRAT table parser and data structures

The following patchset adds NUMA support to the hypervisor. This includes: - A full SRAT table parser for 32-bit and 64-bit, based on the ACPI NUMA parser from linux 2.6.16.29 with data structures to represent NUMA cpu and memory topology, and NUMA emulation (fake=). - Changes to the Xen page allocator adding a per-node bucket for each zone. Xen will continue to prioritize using the

The patchset will add basic NUMA support to Xen (hypervisor only). We borrowed from Linux support for NUMA SRAT table parsing, discontiguous memory tracking (mem chunks), and cpu support (node_to_cpumask etc). The hypervisor parses the SRAT tables and constructs mappings for each node such as node to cpu mappings and memory range to node mappings. Using this information, we also modified the

Once Xen calculates nr_nodes properly, all nr_cpu calculations based on nr_nodes * sockets_per_node * cores_per_socket * threads_per_core are broken. The easy fix is to replace those calculations with a new field, nr_cpus in physinfo which is calculated by num_online_cpus(). This patch does so and attempts to change all users over to nr_cpus field in physinfo. This patch touches

This patch -Displays[1] current parameters for running domains ala xm list -Allow users to set[2] one or more parameters[3] without having to provide values for parameters they do not wish to change -Adds additional testing of sched-sedf via new xm-test testcases. With this patch applied, test 02_sedf_period_lower_neg.py exposes a bug[4]. I''ll follow up this email with a patch for

This patch modifies the physinfo hcall to export NUMA CPU and Memory topology information. The new physinfo hcall is integrated into libxc and xend (xm info specifically). Included in this patch is a minor tweak to xm-test''s xm info testcase. The new fields in xm info are: nr_nodes : 4 mem_chunks : node0:0x0000000000000000-0x0000000190000000

I''ve been looking into bug [1]#195 and I have a couple of questions on how timer interrupts and virqs are handled. Is it possible for dom0 linux to irq balance timer interrupts to different cpus? That is, if xen sends a VIRQ_TIMER to vcpu0, backed by cpu0, is it possible for that interrupt to be handled by vcpu1, backed by cpu1 ? After putting in some debug code in to timer_interrupt

This patch adds a per-node bucket to the heap structure in Xen. During heap initialization the patch determines which bucket to place the memory. We reserve guard pages between node boundaries in the case that said boundary isn''t already guarded by the MAX_ORDER boundary to prevent the buddy allocator from merging pages between nodes. -- Ryan Harper Software Engineer; Linux Technology

I''m working on a new hypercall, do_confer, which allows the directed yielding of a vcpu to another vcpu. It is mainly used when a vcpu fails to acquire a spinlock, yielding to the lock holder instead of spinning. I ported the ppc64 spinlock implementation for the i386 linux portion. In implementing the hypercall, I''ve been trying to figure out how to get the scheduler

I''ve put together two patches. The first introduces a new dom0_op, set_max_vcpus, which with an associated variable and a check in the VCPUOP handler fixes [1]bug 288. Also included is a new VCPUOP, VCPUOP_create, which handles all of the vcpu creation tasks and leaves initialization and unpausing to VCPUOP_initialize. The separation allows for build-time allocation of vcpus which

This patch adds new control messages for vcpu hotplug events. Via the xm vcpu_hotplug sub-program, VCPUS in domains can be enabled/disabled when CONFIG_HOTPLUG_CPU is enabled in the target domain''s kernel. Currently there is nothing that tracks whether a VCPU is up or down. My previous [1]patch added a new per-VCPU flag (VCPUF_down) which could be used to keep track of which VCPUS are

We currently compare the sum of the pages found in the SRAT table to the address of the highest memory page found via the e820 table to validate the SRAT. This is completely bogus if there''s any kind of discontiguous memory, where the sum of the pages could be much smaller than the address of the highest page. I think all that''s necessary is to validate that each usable memory

From: Ryan Harper <ryanh at us.ibm.com> Rather than faking up some geometry, allow the backend to push the disk geometry via virtio pci config option. Keep the old geo code around for compatibility. Signed-off-by: Ryan Harper <ryanh at us.ibm.com> Reviewed-by: Anthony Liguori <aliguori at us.ibm.com> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index

From: Ryan Harper <ryanh at us.ibm.com> Rather than faking up some geometry, allow the backend to push the disk geometry via virtio pci config option. Keep the old geo code around for compatibility. Signed-off-by: Ryan Harper <ryanh at us.ibm.com> Reviewed-by: Anthony Liguori <aliguori at us.ibm.com> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index

That change converted the (wrong) assumption of contiguous nodes'' memory to a similarly wrong one of assuming discontiguous memory (i.e. each node having separate E820 table entries). The code ought to be able to deal with both, though, and I hope this change makes it so. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2009-08-24.orig/xen/arch/x86/srat.c 2009-08-28

Using Rusty's suggestion I've respun the patch removing the special copy function. I've tested this patch in a guest kernel with and without qemu supplying serial numbers for the block devices and it's working as expected. When qemu supplies serial numbers, the correct value is supplied to /sys/block/vdX/serial and can be used by udev for generating disk/by-id paths (without

Using Rusty's suggestion I've respun the patch removing the special copy function. I've tested this patch in a guest kernel with and without qemu supplying serial numbers for the block devices and it's working as expected. When qemu supplies serial numbers, the correct value is supplied to /sys/block/vdX/serial and can be used by udev for generating disk/by-id paths (without

Add a kernel parameter, vendor= which takes a path to a script embedded in the image. If this script is executable, we will then source it during ovirt-early start() after command line processing and before mounting of /config. We also call a post hook at the end of ovirt-early start(). Also include a sample vendor script. Signed-off-by: Ryan Harper <ryanh at us.ibm.com> ---

On 12.12.19 22:43, Rafael J. Wysocki wrote: > On Thursday, December 12, 2019 6:11:25 PM CET David Hildenbrand wrote: >> Will be needed by virtio-mem to identify the node from a pxm. >> >> Cc: "Rafael J. Wysocki" <rjw at rjwysocki.net> >> Cc: Len Brown <lenb at kernel.org> >> Cc: linux-acpi at vger.kernel.org >> Signed-off-by: David

Will be needed by virtio-mem to identify the node from a pxm. Acked-by: "Rafael J. Wysocki" <rafael at kernel.org> Cc: Len Brown <lenb at kernel.org> Cc: linux-acpi at vger.kernel.org Signed-off-by: David Hildenbrand <david at redhat.com> --- drivers/acpi/numa/srat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/numa/srat.c

On Mon 02-03-20 14:49:31, David Hildenbrand wrote: > Will be needed by virtio-mem to identify the node from a pxm. No objection to export the symbol. But it is almost always better to add the export in the patch that actually uses it. The intention is much more clear that way. > Acked-by: "Rafael J. Wysocki" <rafael at kernel.org> > Cc: Len Brown <lenb at