| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] SMP designs and discuss
>From: Tristan Gingold
>Sent: 2005年10月14日 21:06
>Hi,
>
>here is a list of point I'd like to share and to discuss with you.
>Please, comment and do not hesitate to cut this mail to create new threads.
Good topics, Tristan!
>* scheduler spin-lock.
> Currently, I use an hack to release the spin-lock acquired in
> __enter_schedule. This is done in schedule_tail.
> The problem is during the first activation of a domain: the spin-lock is
> acquired, but context_switch never returns, and on x86 the spin-lock is
> released after context_switch.
I see your approach the right way to go. Since there're two execution paths
right after context_switch(), you have to release the lock on both paths.
>
>
>* Idle regs.
> Currently, idle domains have no regs (the regs field is NULL).
> [I am not sure it is true for idle0].
> Is it a problem ?
> I had to modify the heartbeat so that it doesn't reference regs.
>
>
>* Why xentime.c is so complicate ?
> What is the purpose of itc_at_irq, stime_irq ?
The ns is always required by other places in xen which requires time query
(NOW()), so arch specific time handler has to maintain the conversion between
cycles and ns. To keep the accuracy of math calculation, shift is used and so
to prevent overflow, the conversion is usually made upon relative smaller
offset. Then stime_irq and itc_at_irq provides timestamp when last time
interrupt happens, with the former with ns and latter for cycle.
>
>
>* Xenheap size.
> It is too small for more than 2 cpus.
> Maybe its size must depends of MAX_CPUS ?
When we see xenheap size not enough, first is to scan whether any allocation
shouldn't happen in xenheap. In the early design, some allocations are not
carefully differentiated between using xenheap or domheap. But yes, since ia64
has larger set of machine states with more processors, size of xenheap is
likely to be more flexible. Maximum supported pages size by TR is the up
limitation. ;-)
>
>
>* I'd like to catch memory access out of Xen.
> I think it is very easy for code (just remove TR size). Also alt_itlb_miss
> must crash Xen.
Sorry not quite catch above sentence. Why crach Xen?
> Maybe quite more difficult for data. I have to identify where Xen try to
> access out of its data region. Here is a first try:
> * mmio(serial/vga/...) (can be mapped)
> * ACPI tables (can be copied)
> * Call to PAL/SAL/EFI (can enable alt_dtlb_miss)
Is there any limitation about hypervisor's ability? Xen should be able to
access all the address space. Why do you need to differentiate those types?
Thanks,
Kevin
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home