The reason is that recent change upon vcpu time affects offset of
arch.flag within shared_info_t which, however is not sync-ed into
xenolinux. So when dom0 tries to access shared_info_t->arch.flag, it
gets incorrect flag 0 which simply mean as domU. Then dom0 tries to
bring up frontend driver, instead of backend, and finally halt due to no
response for ctrl message.
With following patch upon xenolinux, I can see dom0 + domU up again.
Signed-off-by Kevin Tian <Kevin.tian@xxxxxxxxx>
Thanks,
Kevin
--- xenolinux.0/include/asm-xen/xen-public/xen.h 2005-07-28
19:26:59.000000000 +0800
+++ xenolinux.1/include/asm-xen/xen-public/xen.h 2005-08-03
13:57:12.000000000 +0800
@@ -58,7 +58,7 @@
#define __HYPERVISOR_boot_vcpu 24
#define __HYPERVISOR_set_segment_base 25 /* x86/64 only */
#define __HYPERVISOR_mmuext_op 26
-#define __HYPERVISOR_policy_op 27
+#define __HYPERVISOR_acm_op 27
/*
* VIRTUAL INTERRUPTS
@@ -329,6 +329,28 @@ typedef struct vcpu_info {
#endif
} vcpu_info_t;
+typedef struct vcpu_time_info {
+ /*
+ * The following values are updated periodically (and not
necessarily
+ * atomically!). The guest OS detects this because 'time_version1'
is
+ * incremented just before updating these values, and
'time_version2' is
+ * incremented immediately after. See the Xen-specific Linux code
for an
+ * example of how to read these values safely
(arch/xen/kernel/time.c).
+ */
+ u32 time_version1;
+ u32 time_version2;
+ u64 tsc_timestamp; /* TSC at last update of time vals. */
+ u64 system_time; /* Time, in nanosecs, since boot. */
+ /*
+ * Current system time:
+ * system_time + ((tsc - tsc_timestamp) << tsc_shift) *
tsc_to_system_mul
+ * CPU frequency (Hz):
+ * ((10^9 << 32) / tsc_to_system_mul) >> tsc_shift
+ */
+ u32 tsc_to_system_mul;
+ s8 tsc_shift;
+} vcpu_time_info_t;
+
/*
* Xen/kernel shared data -- pointer provided in start_info.
* NB. We expect that this struct is smaller than a page.
@@ -336,6 +358,8 @@ typedef struct vcpu_info {
typedef struct shared_info {
vcpu_info_t vcpu_data[MAX_VIRT_CPUS];
+ vcpu_time_info_t vcpu_time[MAX_VIRT_CPUS];
+
u32 n_vcpu;
/*
@@ -373,33 +397,11 @@ typedef struct shared_info {
u32 evtchn_mask[32];
/*
- * Time: The following abstractions are exposed: System Time, Clock
Time,
- * Domain Virtual Time. Domains can access Cycle counter time
directly.
+ * Wallclock time: updated only by control software. Guests should
base
+ * their gettimeofday() syscall on this wallclock-base value.
*/
- u64 cpu_freq; /* CPU frequency (Hz).
*/
-
- /*
- * The following values are updated periodically (and not
necessarily
- * atomically!). The guest OS detects this because 'time_version1'
is
- * incremented just before updating these values, and
'time_version2' is
- * incremented immediately after. See the Xen-specific Linux code
for an
- * example of how to read these values safely
(arch/xen/kernel/time.c).
- */
- u32 time_version1;
- u32 time_version2;
- tsc_timestamp_t tsc_timestamp; /* TSC at last update of time
vals. */
- u64 system_time; /* Time, in nanosecs, since
boot. */
u32 wc_sec; /* Secs 00:00:00 UTC, Jan 1,
1970. */
u32 wc_usec; /* Usecs 00:00:00 UTC, Jan 1,
1970. */
- u64 domain_time; /* Domain virtual time, in
nanosecs. */
-
- /*
- * Timeout values:
- * Allow a domain to specify a timeout value in system time and
- * domain virtual time.
- */
- u64 wall_timeout;
- u64 domain_timeout;
arch_shared_info_t arch;
@@ -444,7 +446,7 @@ typedef struct start_info {
memory_t mod_start; /* VIRTUAL address of pre-loaded module.
*/
memory_t mod_len; /* Size (bytes) of pre-loaded module.
*/
s8 cmd_line[MAX_GUEST_CMDLINE];
- memory_t store_page; /* VIRTUAL address of store page.
*/
+ memory_t store_mfn; /* MACHINE page number of shared page.
*/
u16 store_evtchn; /* Event channel for store communication.
*/
} start_info_t;
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home