similar to: xen_domain_handle_t usage

It seems that xenstore watches do not work from domU userspace (they obviously do for drivers). In some preliminary debugging of this, there are two aspects of the failure: not sending the watch to xenstore and not handling watch events for userspace watches. The former can be easily fixed by adding the missing ''case XS_WATCH:'' to xenbus_dev_write() in xenbus_dev.c. The

I have problem to start domU with errors: # xm create -c x335-hien1-vm4.cfg Using config file "x335-hien1-vm4.cfg". Error: Device 0 (vif) could not be connected. Hotplug scripts not working in changeset: changeset: 7700:98bcd8fbd5e36662c10becdcd0222a22161bb2b6 tag: tip user: kaf24@firebug.cl.cam.ac.uk date: Tue Nov 8 09:48:42 2005 summary: Fix alloc_skb()

We have test latest xen (ChangeSet 7608) on VT platform with Intel 915 chipset and Here is the test summary: IA32: Build&Boot SMP xen0 without problem Can startup XenU with different configuration IA32 issues contain: VMX can not be created IA32E: Build&Boot SMP xen0 without problem Can startup XenU with different configuration IA32E issues

After upgrading to 3.0.2 I tried rebooting a domU (a problem sometimes in 3.0.1 related to bug 514) it failed to come back up. This was in my xend.log. ("Refusing to restart to avoid loops." .... ) [2006-04-11 20:53:39 xend.XendDomainInfo] DEBUG (__init__:988) Storing domain details: {''console/ring-ref'': ''223144'', ''console/port'':

This seems exceptionally evil and is definitely a PITA. What was the original problem that led us to do this? I''d like to take a stab at correcting it so we can have a more sane installation. Regards, Anthony Liguori _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

I''m running Xen3 7775 with udev 073 (which was a PITA to get working, as the initrd I''ve been running for quite some time uses an older one -- but that''s an entirely different story). My dom0 is Gentoo-based. When I try to start a DomU, it times out waiting for hotplug-based notification, as per the following: DEBUG (DevController:69) Waiting for devices vif. DEBUG

I''m running Xen3 7775 with udev 073 (which was a PITA to get working, as the initrd I''ve been running for quite some time uses an older one -- but that''s an entirely different story). My dom0 is Gentoo-based. When I try to start a DomU, it times out waiting for hotplug-based notification, as per the following: DEBUG (DevController:69) Waiting for devices vif. DEBUG

With sles 10, ''make tools'' produces the following: CFLAGS="-O2 -fomit-frame-pointer -DNDEBUG -m32 -march=i686 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_INTERFACE_VERSION__=0x00030101" python setup.py install --home="/root/xen/xen-unstable.hg/dist/install/usr" --force running install error: must supply either home or prefix/exec-prefix --

This patch causes "xm mem-set" to be lower bound on domX-min-mem option in xend-config. Another configuration option called domU-min-mem has been introduced, which works similarly to dom0-min-mem. This is prevents users from freezing the system when doing "xm mem-set" on very low values like 32M. Signed-off-by: Aravindh Puthiyaparambil

hi, I am trying to add xenbus watch support to mini-os, but am getting into a endless loop of watches firing over and over. Below is an excerpt from the xenstore tracefile: IN 0x805acc8 20070103 19:32:18 WATCH (/local/domain/0/backend/vif/26/0/state 00043818 ) CREATE watch 0x805a8b8 OUT 0x805acc8 20070103 19:32:18 WATCH (OK ) OUT 0x805acc8 20070103 19:32:18 WATCH_EVENT

As any other daemon, I''d assume it should be possible to restart xenstored (i.e. if it crashed or if, during development, a fix was made to it that needs to be tested). However, as I learned after over a day of digging, things don''t work anymore after doing so: Since the watches are transient, they''re lost with the daemon going away. Right now I specifically need this in

Hi Ewan/Alistair, I have a patch that looks like this: diff -r a39ad4c78850 tools/libxc/xenctrl.h --- a/tools/libxc/xenctrl.h Wed Aug 30 13:51:12 2006 +0100 +++ b/tools/libxc/xenctrl.h Wed Aug 30 15:11:20 2006 -0500 @@ -416,6 +416,10 @@ int xc_domain_memory_populate_physmap(in unsigned int address_bits, xen_pfn_t

When does vif0.0 get created? Is there some shell magic? I''m trying to figure out how to do a similar peth1/veth1 split for eth1. -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, Xm list and xm vcpu-list show wrong DomID(name). Under this situation, # xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 512 1 r----- 1064.6 test1 13 64 1 r----- 83879.7 # xm list 1 13 Error: Domain ''1'' not found when running ''xm list'' # xm list

APIs such as sh_invlpg and sh_update_cr3 take a pointer to the virtual cpu on which it needs to operate as an argument. However, it appears that the call can only operate on the currently executing vcpu. Regards, K. Y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Ewan Mellor wrote: >> >> Ian Pratt wrote: >>> >>> >>>> I have been trying for days now to get a working nat setup with >> my >>>> domU''s using the default nat scripts. >>> Just look at what the demo CD does for a nice example of how to set up >>> NAT. >>> >>> Ian >>> >>

(Short version:) Here is a temporary fix for a Xen build problem when using Python 2.4: cd xen-unstable/ sed -i ''s/--home/--prefix="" --home/'' tools/python/Makefile sed -i ''s/--home/--prefix="" --home/'' tools/pygrub/Makefile sed -i ''s/--home/--prefix="" --home/'' tools/security/Makefile (Long version:)

Attached patch fixes a problem in marshaling large integers. It seems to only occur on systems with very large memory. However, on those systems, it''s a show-stopper. I see this as a temporary solution until we can sanitize the XML-RPC functions and get rid of all the S-Expression stuff. I''ll run xm-test tomorrow against it. Right now I''ve only done basic

Hi, I encountered a problem while porting Solaris as a guest OS on Xen. The problem I found is that when frontend vbd driver get unloaded, it will close the vbd interface by changing the state to XenbusStateClosed. This appears to cause the dom0 hotplug scripts to remove the vbd entry from xenstore for the domU guest, preventing the vbd from being re-attached. So, my questions are: + This

This patch fixes the bug that "xm reboot <domid>" can not reboot vmx domain. In xm reboot process, control panel will wait until DomU notified it. Unlike DomU, vmx domain can not passively do that, since it runs unmodified OS. This patch adds the missing logic in control panel. Any comment? Signed-off-by: Xu Dan <dan.d.xu@intel.com > Yu Ke