From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: rendezvousing all physical CPUs Date: Fri, 01 Dec 2006 08:16:40 +0000 Message-ID: <456FF2F8.76E4.0078.0@novell.com> References: <456F116D.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 30.11.06 17:55 >>> >On 30/11/06 16:14, "Jan Beulich" 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