Andi Kleen wrote: >> There was one other point I wanted to make but I forgot it now @) >> > > Ah yes the point was that since most of the implementations of the hypercalls > likely need fast access to some per CPU state. How would you plan > to implement that? Should it be covered in the specification? > Probably. We don't have that issue currently, as we have a private mapping of CPU state for each VCPU at a fixed address. Seeing as that is not so feasible under Xen, I would say we need to put something in the spec. The way Xen deals with this is rather gruesome today. It needs callbacks into the kernel to disable preemption so that it can atomically compute the address of the VCPU area, just so that it can disable interrupts on the VCPU. These contortions make backbending look easy. I propose an entirely different approach - use segmentation. This needs to be in the spec, as we now need to add VMI hook points for saving and restoring user segments. But in the end it wins, even if you can't support per-cpu mappings using paging, you can do it with segmentation. You'll likely get even better performance. And you don't have to worry about these unclean callbacks into the guest kernel that really make the interface between Xen and XenoLinux completely enmeshed. And you can disable interrupts in one instruction: movb $0, %gs:hypervisor_intFlags Zach
