state of guest at start-up

state of guest at start-up

[Max Dmitrichenko]

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

Re: state of guest at start-up

[Keir Fraser]

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

Ответ: state of guest at start-up

[Max Dmitrichenko]

> > 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

Re: Ответ: state of guest at start-up

[Keir Fraser]

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

Re: Ответ: state of guest at start-up

[Max Dmitrichenko]

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