[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Ответ: [Xen-devel] state of guest at start-up
> 2) What is the meaning of shared_info.vcpu_info[0].evtchn_upcall_mask? > I thought that it masks all the event channels on the VCPU #0, but > this seems wrong, i.e. when I set this to 0xff, the hypervisor > callback is still being called. I have to set the > shared_info.evtchn_mask to all ones in order to mask all the event > channels. Is this behavour correct? No. vcpu_info[cpu].evtchn_upcall_mask definitely stops callbacks via the hypervisor_callback. Hm... I'll check myself once more, but yesterday I have spent some amount of time investigating very strange behavior. I was doing an output on the domU console and notifying the console event channel and I saw that output was done twice. After several attemps to understand this, I realized that after notifying with event_channel_op(EVTCHN_send) the callback was called. Since I had't had setup the callback, the callback was called at the address 0x0000000 which was the entry point to the OS booting and the whole process started once again and that caused the second output to the domU console. The strange thing is that I haven't explicitly enabled interrupts, i.e. I haven't written a zero to the event_upcall_mask of 0th VCPU. So why then the callback was called? > 3) How to determine current VCPU number? As you would if running natively -- probably by stack-pointer arithmetic and have some per-cpu info stashed at the bottom of the stack page. Hm... I've always thought, that if running natively I would ask the APIC, OpenPIC or something similar about my processor ID. Why not to do this way under Xen? For example, Xen could make available a separate page which is private to any VCPU and this page will contain the number of it among other sweet things. > 4) When I map the shared_info MFN into my OS's space via > update_va_mapping hypercall and then take the dump of the domain with > `xm dump-core -C ...`, the page where the shared_info supposed to be > mapped to is filled with all zeroes. Is this normal, of that means > that mapping was unsuccessful. If you don't include the shared_info page in your phys-to-machine map then dump-core will not dump the page contents. But update_va_mapping() includes the page in the phys-to-machine map, doesn't it? If not then how to do this? -- Max _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |