search for: device_hotplug

Hi, I''m using a custom block script in my xen setup and when started, it creates a new device node pointing to some network resources. Now I noticed that the script is called twice for the root block, the first time for pygrub most likely, but is only stopped once ... I don''t mind creating two devices node, but then I need to destroy both ... Is this a known issue ? Cheers,

...2 ok libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x9cf248 wpath=/local/domain/0/backend/vbd/10/768/state token=3/0: deregister slotnum=3 libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x9cf248: deregister unregistered libxl: debug: libxl_device.c:916:device_hotplug: calling hotplug script: /etc/xen/scripts/block add libxl: debug: libxl_event.c:426:watchfd_callback: watch epath=/local/domain/0/backend/vbd/10/768/state token=3/0: empty slot libxl: debug: libxl_dm.c:1142:libxl__spawn_local_dm: Spawning device-model /usr/lib/xen/bin/qemu-system-i386 with argument...

Hi, Here is a little patch that attempt to fix the issue regarding xen_platform_pci=0 not been handled. There is one patch left from the previous version. The patch that was adding qemu_machine_override have been removed as it is unnecessary. If someone wants to change the -machine, it can always add it to device_model_args_hvm, as QEMU appear to use the last one. Regards, Anthony PERARD (1):

...-git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 7bac38764513d..b57b2067ecbfb 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -331,7 +331,7 @@ static enum bp_state reserve_additional_memory(void) mutex_unlock(&balloon_mutex); /* add_memory_resource() requires the device_hotplug lock */ lock_device_hotplug(); - rc = add_memory_resource(nid, resource, 0); + rc = add_memory_resource(nid, resource, MEMHP_MERGE_RESOURCE); unlock_device_hotplug(); mutex_lock(&balloon_mutex); -- 2.26.2

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Package: xen-utils-common Version: 4.4.1-6 Severity: normal Dear Maintainer, (There appear to be several reports on the BTS with concerns relating to this report. Some unarchiving/merging may be necessary. Reassignment may be needed as well since I'm not sure which package this problem would fall under. Ultimately decided to file with xen-utils-common with 'xl' being the frontend

...-git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 51427c752b37b..7bac38764513d 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -331,7 +331,7 @@ static enum bp_state reserve_additional_memory(void) mutex_unlock(&balloon_mutex); /* add_memory_resource() requires the device_hotplug lock */ lock_device_hotplug(); - rc = add_memory_resource(nid, resource); + rc = add_memory_resource(nid, resource, 0); unlock_device_hotplug(); mutex_lock(&balloon_mutex); diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h index 51a877fec8da8..5cd48332ce119 10...

...-git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 51427c752b37b..9f40a294d398d 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -331,7 +331,7 @@ static enum bp_state reserve_additional_memory(void) mutex_unlock(&balloon_mutex); /* add_memory_resource() requires the device_hotplug lock */ lock_device_hotplug(); - rc = add_memory_resource(nid, resource); + rc = add_memory_resource(nid, resource, MHP_NONE); unlock_device_hotplug(); mutex_lock(&balloon_mutex); diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h index 51a877fec8da8..e53d1058f...

...ok libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch w=0x193f648 wpath=/local/domain/0/backend/vif/6/0/state token=3/1: deregister slotnum=3 libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch w=0x193f648: deregister unregistered libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge online libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug script: /etc/xen/scripts/vif-bridge add libxl: debug: libxl_event.c:1737:libxl__ao_progress_report: ao 0x193a970: progress report: ignored libxl: debug: libxl_event.c:1569...

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

This is the follow up of [1]: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools I realized that this is not only helpful for virtio-mem, but also for dax/kmem - it's a fix for that use case (see patch #3) of persistent memory. Also, while testing, I discovered that kexec-tools will *not* add dax/kmem memory (anything not directly under the root when parsing

This series is based on [1]: [PATCH v2 00/10] virtio-mem: paravirtualized memory That will hopefull get picked up soon, rebased to -next. The following patches were reverted from -next [2]: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use As discussed in that thread, they should be reverted from -next already. In theory, if people agree, we could take the first two patches

I''m unable to start xl console on latest xen-unstable (build with commit 8e0da8c07f4f80e14314977a11f738bd74a5b62b). > xl -vvv console sid > xenconsole: Could not read tty from store: No such file or directory I also tried "xl create -c", and it shows console from pygrub but when the "xl create" reaches the end I got the same error: > xenconsole: Could not

*RESEND* due to exceeding the mailinglists limit for attachment size. Hi, I''m trying to get secondary vga-passthrough on a HVM guest to work with a AMD HD6570 and the native kernel radeon driver and kernel modesetting. So the guest still gets the emulated stdvga or cirrus device(used in my case here) as primary/boot vga adapter. - When i don''t passthrough the radeon card, the