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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
