Xen Scheduler has been changed a lot recently. It is focusing on multiprocessor management and performance isolation across VMs.

1. EACH domain (include domain 0) binds a number of VCPUs to a subset of of physical CPUs;
2. For each domain, the number of binding VCPUs is equal to the number of bound PCPUs;
3. At start of day, each bound PCPU is allocated a time slice for each binding domain (may include Domain 0);
4. As time elapses, the weights of VCPUs bound to a PCPU would be adjusted to fullfill different needs from VMs;
5. It could not fulfill the gang scheduling needs from guests till this point, but the development is on going;
6. It is possible that Dom0 is running on a separate CPU (set your CPU-list in the config such that Dom0 has one particular CPU-core, and the Guest domain uses a different CPU-core - that way, you don't have to wait for the “other CPU to be ready” when it's swithcing between Dom0 and DomU). Again, it's hard to say exactly how much you get from this, but it should give you some benefit;
7. Xen allows a domain's virtual CPU(s) to be associated with one or more host CPUs. This can be used to allocate real resources among one or more guests, or to make optimal use of processor resources when utilizing dual-core, hyperthreading, or other advanced CPU technologies.
8. Xen enumerates physical CPUs in a `depth first' fashion. For a system with both hyperthreading and multiple cores, this would be all the hyperthreads on a given core, then all the cores on a given socket, and then all sockets. I.e. if you had a two socket, dual core, hyperthreaded Xeon the CPU order would be:

                                                      socket0                socket1
                                                 core0      core1       core0       core1
                                               ht0   ht1   ht0   ht1   ht0   ht1   ht0   ht1
                                               #0    #1    #2    #3    #4    #5    #6    #7

1. Having multiple vcpus belonging to the same domain mapped to the same physical CPU is very likely to lead to poor performance. It's better to use `vcpus-set' to hot-unplug one of the vcpus and ensure the others are pinned on different CPUs.
2. If you are running IO intensive tasks, its typically better to dedicate either a hyperthread or whole core to running domain 0, and hence pin other domains so that they can't use CPU 0. If your workload is mostly compute intensive, you may want to pin vcpus such that all physical CPU threads are available for guest domains.
3. The SEDF-based resource management strategy for CPU allocations is approximate and sacrifices much utilization to compensate for the relative lack of control that SEDF provides over CPU allocations for I/O intensive operations. The alternative schedulers that address the SEDF shortcomings is Credit Scheduler.

http://www.xensource.com/files/summit_3/sched.pdf
http://wiki.xensource.com/xenwiki/XenRoadMap?action=AttachFile&do=get&target=xenroad.pdf
http://www.hpl.hp.com/personal/Lucy_Cherkasova/papers/xenqos-mware-camera-ready.pdf
http://lists.xensource.com/archives/html/xen-devel/2006-10/msg00764.html
http://workspace.globus.org/papers/Division_Of_Labor_ICSOC.pdf (Page 6-7)

Network performance:
http://www.bullopensource.org/xen/benchs.html
http://lists.xensource.com/archives/html/xen-users/2006-11/msg00747.html

1. Event channels are addressed by a “port index”. Each channel is

associated with two bits of information:

  1) PENDING -- notifies the domain that there is a pending notification to be processed. This bit is cleared by the guest.
  2) MASK -- if this bit is clear then a 0->1 transition of PENDING will cause an asynchronous upcall to be scheduled. 
             This bit is only updated by the guest. It is read-only within Xen. 
             If a channel becomes pending while the channel is masked then the 'edge' is lost 
             (i.e., when the channel is unmasked, the guest must manually handle pending notifications as no upcall will be scheduled by Xen).

1. Event channels are used to inject events into the kernel, either from the hypervisor or from another VM. The injected events are mapped to interrupts. If an event needs to be injected, the hypervisor causes an upcall into the kernel. The upcall handler then scans the event pending bitmap and calls do_IRQ for each pending event.