Re: [RFC, PATCH 1/24] i386 Vmi documentation II

[Zachary Amsden]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/