Re: rendezvousing all physical CPUs

["Jan Beulich" <jbeulich@novell.com>]

>>> Keir Fraser <keir@xensource.com> 30.11.06 17:55 >>>
>On 30/11/06 16:14, "Jan Beulich" <jbeulich@novell.com> wrote:
>
>> Will it be acceptable to create hypercall sub-functions (would probably go
>> into the platform group, but should be architecture independent) to allow
>> Dom0 to halt all physical CPUs but the current one, and later restart them?
>> Or should it rather be a single call with an event-channel based call back
>> to carry out the operation that must be protected?
>
>How about providing the linear address of a chunk of dom0 code that Xen
>should run in ring 0 with CPUs in a particular configuration? We could
>provide flags to represent useful configurations: e.g., run on all CPUs
>atomicaly, run on CPU0 only and quiesce others, etc.

Hmm??? I would have to question why dom0 currently gets run in ring 1 then.

I would at best consider allowing the guest to pass a batch of operations that
it wants carried out - I/O memory accesses (normal RAM not allowed), MSR
reads/writes, port I/O. However, for the specific case of the RNG, PCI config
space accesses would also need to be supported - while they can be reduced
to iomem or port accesses, abstracting this out from the requester and from
Xen would require some thought.

>As you say this could be used for things arguably more useful than this RNG
>example, like microcode updates and maybe even the MTRR updates could be
>done in dom0 too, which would be very nice. :-)

While the RNG example may seem odd or unimportant, the point is that
currently this doesn't present a problem only because apparently no-one
but dom0 can actually see (physical) BIOS memory space (and hence depend
on its contents). I wonder if that is a proper assumption for I/O domains
currently and/or long term, since XEN_DOMCTL_iomem_permission allows
doing such.

Certainly, I agree that using this for MTRR handling (along with microcode
updating) if feasible would be very handy maintenance wise.

Jan