I would push a new command xm pcpu-list that reports physical
CPU configuration.
I suppose that Xen works on a machine where a lot of physical
CPUs are installed. It is useful for users to know the
configuration of physical CPUs so that they can allocate VCPUs
efficiently. This command
I believe ppc has paravirtualized spinlocks in their Linux
kernel, though even this won't necessarily help with a poorly
written SMP application.
We have an equivalent of this (bad pre-emption mitigation), along with
an alternative (bad pre-emption avoidance). Both have various pros and
I understand and sympathize with the need for dom0 to
sometimes get and use information from each processor that is
only available if dom0 is running on each processor.
However, AFAIK, SMP guests are always gang-scheduled, correct?
No, there's no need to strictly gang schedule, and the
FYI, cset 9434 (Switch the default build to make the -xen
kernel, not the -xen0 and -xenU) breaks xen/ia64 as we do not
currently have a linux-defconfig-xen_ia64. I don't
understand why such a change is being made so close to Xen
3.0.2. Can we make this architecture dependent?
Can
Actually, after thinking about this, it's a bit more complicated
because of the possibility that a DMA may address more than
one page.
If so, a simple DMA may need to be translated into a scatter-gather
(or a scatter-gather into a more complex scatter-gather).
Not impossible,
