Re: Nested events in 64bit mini-OS

[Xu Zhang <xzhang@cs.uic.edu>]

>>> +    .byte 0x78,0x78,0x78,0x78,0x78            # jmp    
>>> hypercall_page + (__HYPERVISOR_iret * 32)
>> Here we would also need a fixup table for the code at hypercall_page!
> Nice catch!
>
>> A nicer fix would be to inline the hypercall code here.
After a second thought, it seems to me such "expansion" of 
hypercall_page into fixup table is not necessary (and wrong). Insead, we 
can and need to mask out events before we doing a hypercall iret. I 
think it is safe (and must, see below) to do this because:
1. if event is disabled: doesn't hurt to mask it again;
2. if event is enabled: we disable event, and jumps to hypercall_page to 
make a hypercall iret, which eventually calls do_iret:

In do_iret, line 309:
      /* Restore upcall mask from supplied EFLAGS.IF. */
      vcpu_info(v, evtchn_upcall_mask) = !(iret_saved.rflags & 
X86_EFLAGS_IF);

No matter what the current value of upcall mask is, do_iret always 
retores it to the negation of rflags.IF saved on stack. In other words, 
it is safe to mask upcall mask before hypercall iret. And in fact, I am 
afraid it's necessary that we make it a must, because even one can guard 
against nested events in guest OS, but can never do so on hypercall page 
(because the code is in Xen). We should never jump to hypercall_page 
iret with events enabled. So we have to set upcall mask before the jump. 
I guess that's one of the reason why Xen always restores upcall mask 
from stack.


>> Also, it would be good to check against critical section size change, in
>> case somebody e.g. changes a value, or a macro like XEN_PUT_VCPU_INFO.
>> For instance, stuff right after the table:
>>
>>     .if (ecrit-scrit) != (critical_fixup_table_end - 
>> critical_fixup_table)
>>     .error "The critical has changed, the fixup table needs updating"
>>     .endif
> Totally agree. And it somewhat saves the obligation of checking if the 
> table size matches the one of critical section by looking at 
> disassemble output. :-)
>
>
Correct me if I am wrong, I think hypercall_page is mapped at runtime to 
guest OS by Xen. It's not actually part of the critical section of guest 
OS, at least not at compile time. So having a fixup table for the code 
at hypercall_page would cause such check to fail (mismatch). Following 
the discussion above, we could easily avoid such fixup table by mask out 
the events.

I don't know if this make sense at all. :-)