Hi! I''m currently trying to port one small real-time OS to Xen and have couple of questions which I didn''t find in the documentation. 1) What are the status of event channels mask at the start of the day? My experiments showed that all the event channels are unmasked - is this right? In the sources of Mini-OS, I have found a comment saying that event channels are masked at the start. But this seems to be obsolete, or do I make something wrong? 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? 3) How to determine current VCPU number? 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. -- Thanks in advance, Max _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 4/4/07 09:46, "Max Dmitrichenko" <dmitrmax@gmail.com> wrote:> 1) What are the status of event channels mask at the start of the day? > My experiments showed that all the event channels are unmasked - is > this right? In the sources of Mini-OS, I have found a comment saying > that event channels are masked at the start. But this seems to be > obsolete, or do I make something wrong?The vcpu_info[cpu].evtchn_upcall_mask fields are all set to 1. This prevents upcalls on all vcpus. The per-event-channel masks (shared_info.evtchn_mask) is initialised to all zeroes.> 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.> 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.> 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > 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@lists.xensource.com http://lists.xensource.com/xen-devel
On 4/4/07 23:39, "Max Dmitrichenko" <dmitrmax@gmail.com> wrote:> 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?If you have called SCHEDOP_block at any point, that will automatically clear evtchn_upcall_mask.> 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.Noone does it that way. You either look at your stack pointer or have a CPU-specific segment stashed in fs or gs. We can''t give you a special per-cpu information page at a fixed virtual address because page tables can be shared across CPUs (e.g., if you have a multi-threaded application) and in that case you can''t have different mappings at the same virtual address on different CPUs.>> 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?If you''re building a plain paravirtual guest then you own the phys-to-machine map. Xen knows nothing about it and will not update the phys-to-machine map (or the machine-to-phys map) when you do an update_va_mapping. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2007/4/5, Keir Fraser <Keir.Fraser@cl.cam.ac.uk>:> On 4/4/07 23:39, "Max Dmitrichenko" <dmitrmax@gmail.com> wrote: > > > 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? > > If you have called SCHEDOP_block at any point, that will automatically clear > evtchn_upcall_mask.Yes, I did that call. Thanks for reading my mind :)> > 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. > > Noone does it that way.Really? Then have a look at this: http://lkml.org/lkml/2007/4/4/124 :))> >> 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? > > If you''re building a plain paravirtual guest then you own the > phys-to-machine map. Xen knows nothing about it and will not update the > phys-to-machine map (or the machine-to-phys map) when you do an > update_va_mapping.Ok. Got it. Thanks a lot. -- Max _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel