From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/15] Review: acpi processor hotplug Date: Sun, 24 Feb 2008 11:44:58 +0200 Message-ID: <47C13C9A.3000202@qumranet.com> References: <1203716079-4872-1-git-send-email-gcosta@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, chrisw@sous-sol.org, marcelo@kvack.org To: Glauber Costa Return-path: In-Reply-To: <1203716079-4872-1-git-send-email-gcosta@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Glauber Costa wrote: > Hi, > > In this series, I'm sending the result-so-far of my work > with acpi for processor hotplug. I'm able to put a cpu up and down > (with the help of some udev scripts I wrote), but it still has some > known bugs and issues. For x86_64 linux machines (because the kernel > supports it), you can plug cpus that _were not_ listed initially in > smp_cpus. > > The usage is : cpu_set x (online/offline), in qemu monitor. > It will then send the proper signals to the cpu #x. > > However, it is important to note that: > > * there's no way to know if it suceeded. (ex, if the udev scripts are not > running, the cpu will not be put up, and you'll never know) > * there's no way to unconditionally send an add signal. (if you send BUS_CHECK again, > and the cpu is already marked as present, it will offline it instead) > > because of that, management gets a bit complicated. The ideal situation is to specify: > "I want Y cpus", and have it. Error reported in case it fails. Because of that, I _still_ > advocate for an alternative virtio implementation. ACPI still plays its role in this scenario, > but not the full role. > > Perhaps this can be implemented in userspace; I don't see anything that needs to be in the kernel for this. Since it needs to work independently of networking, maybe it's a good first use for an AF_VIRT protocol family (which can be implemented on top of virtio). > In my TODO list, you'll find: > * fix some more issues in this code, and merge the gently comments I'm sure you'll make > It's difficult with such near-perfect patchsets. You're reducing me to whitespace comments. Please post to qemu-devel as well so they can ignore it as usual. > * device acpi hotplug > * virtio cpu hotplug for linux (meaning refactoring the existing patch) > Slightly related to this would be a qemu monitor mechanism to set vcpu->cpu affinity. > * occupy 24 territories. > * conquer 18 territories with at least 2 battalions on each. > Sounds risky. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/