Re: Ответ: [Xen-devel] state of guest at start-up

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 4/4/07 23:39, "Max Dmitrichenko" <dmitrmax@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel