similar to: [PATCH] update evtchn for SMP

Hello, I''m working with full virtual FreeBSD 8.2-RELEASE-p1 amd64 domU under debian squeeze and xen-hypervisor-4.0-amd64. If I cfg this hvm with cpu > 4 : vcpus = 5 the server is blocked by these messages : fpudna: fpcurthread == curthread XXXX times The machine is pingable but I''m unable to ssh to it. On single user, freebsd works fine, fsck an so on ok, but

# This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/03/23 18:27:49-08:00 kmacy@shemp.lab.netapp.com # only bump tmpindex by NKPT-1 once # release sched lock on upcall # Signed-off-by: Kip Macy <kmacy@fsmware.com> # # freebsd-5.3-xen-sparse/i386-xen/i386-xen/machdep.c # 2005/03/23 18:24:47-08:00 kmacy@shemp.lab.netapp.com +0 -4 # remove extra bump of

The problem occurs after an update of 8-stable from r248120 to r252111. Sometimes shutdown hangs: Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. >From the kernel

Hello, The Xen community is working on a new virtualization mode (or maybe I should say an extension of HVM) to be able to run PV guests inside HVM containers without requiring a device-model (Qemu). One of the advantages of this new virtualization mode is that now it is much more easier to port guests to run under it (as compared to pure PV guests). Given that FreeBSD already supports

Presumably as a result of recent changes, FreeBSD no longer works with writable page tables. In the short-term I''m more interested in functionality than performance. This patch disables them and fixes a compile issue. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/29 19:26:00-07:00 kmacy@curly.lab.netapp.com # disable writable pagetables + compile

Hi, on ia64, the do_* functions for hypercalls are called in C. However, they are not declared in any .h file. I think it is cleaner to declare them in an header file rather than locally. The question is in which header file. Thank you for any suggestion. The do_* functions are at least: extern long do_ni_hypercall(void); extern long do_dom0_op(dom0_op_t *u_dom0_op); extern long

Thanks for the module, I think its a good idea to commit it to FreeBSD for a few reasons: 1) Some folks just prefer more static kernels. 2) Securelevel is a great thing, but can be a pain to do upgrades around remotely. [A lot of folks use FreeBSD simply because its a breeze to run remotely]. 3) Until someone writes code to add modules to a kernel via /dev/mem and releases it to the script

Since IRQ probing may touch all currently unused interrupts, we must prevent probing for those where it doesn''t make sense (to avoid triggering BUG()s or de-referencing NULL function pointers): - dynamic IRQs must never be probed - physical IRQs should only be probed when registered or identity-mapped I haven''t got feedback from the reporting party, yet, but as the change seems

Remove x86 dependency in drivers/xen/events.c for ia64/xen support introducing include/asm/xen/events.h. Introduce xen_irqs_disabled() to hide regs->flags Introduce xen_do_IRQ() to hide regs->orig_ax. make enum ipi_vector definition arch specific. ia64/xen needs four vectors. Add one rmb() because on ia64 xchg() isn't barrier. Signed-off-by: Isaku Yamahata <yamahata at

Remove x86 dependency in drivers/xen/events.c for ia64/xen support introducing include/asm/xen/events.h. Introduce xen_irqs_disabled() to hide regs->flags Introduce xen_do_IRQ() to hide regs->orig_ax. make enum ipi_vector definition arch specific. ia64/xen needs four vectors. Add one rmb() because on ia64 xchg() isn't barrier. Signed-off-by: Isaku Yamahata <yamahata at

PV on HVM guests map GSIs into event channels; at restore time the event channels are resumed by restore_pirqs. Device drivers might try to register the same GSI again through ACPI at restore time, but the GSI has already been mapped and bound by restore_pirqs. This patch detects these situations and avoid mapping the same GSI multiple times. Signed-off-by: Stefano Stabellini

Three of the patches could be squashed in one, but it makes more sense to review them as three. These patches fix the case of an PVHVM guest not being able to resume propely b/c of hitting: 142 BUG_ON(info->type != IRQT_UNBOUND && info->type != type); (in events.c) and also adds a WARN to catch situations like these. The reason for this is that the Xen python toolstack

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

Using the 2.0.6 demo cd image, I booted the supplied freebsd image and rsync''d the file system to an NFS server. However I don not seem to be able to succesfully boot from it the system just hangs here: xn0: bpf attached xn0: Ethernet address: aa:00:00:61:1c:d4 lo0: bpf I have modified /sbin/start_freebsd.sh and /etc/xen/freebsd.py to generate the following configuration: xendemo:~#

Hello, Since FreeBSD 9.1 I have strange problems with the distribution. Some servers are rebooting without any kernel panic, instanly. First i thought it's a problem with my KVM system, but one of my FreeBSD under a Dell R210 have the same problem. The servers concerned are now: - Monitoring server - LDAP test server - Some other servers, randomly (not in production). First i thought it's

This set of patches adds the support for acceleration plugins to the netfront/netback drivers. These plugins are intended to support virtualisable network hardware that can be directly accessed from the guest, bypassing dom0. This is in response to the RFC we posted to xen-devel with an outline of our approach at the end of September. To follow will be another set of patches to provide our

Hi, I have been trying out a nice new tws controller and decided to enable debugging in the kernel and run some stress tests. With a regular GENERIC kernel, it boots up fine. But with debugging, it panics on boot. Anyone know whats up ? Is this something that should be sent directly to LSI ? pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0 pci0: <ACPI PCI bus> on pcib0

I would also like to help as well. As KMacy knows before i asked a lot of questions for T2 types of servers but unfortunately i have no more access to those kind of hardware as well. I;m willing to participate if a team will be formated.