[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 2/3] cpus: Convert cpu_index into a bitmap

From: David Gibson
Subject: Re: [Qemu-devel] [PATCH v3 2/3] cpus: Convert cpu_index into a bitmap
Date: Mon, 25 May 2015 11:05:46 +1000
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, May 21, 2015 at 10:32:07AM +0530, Bharata B Rao wrote:
> Currently CPUState.cpu_index is monotonically increasing and a newly
> created CPU always gets the next higher index. The next available
> index is calculated by counting the existing number of CPUs. This is
> fine as long as we only add CPUs, but there are architectures which
> are starting to support CPU removal too. For an architecture like PowerPC
> which derives its CPU identifier (device tree ID) from cpu_index, the
> existing logic of generating cpu_index values causes problems.
> With the currently proposed method of handling vCPU removal by parking
> the vCPU fd in QEMU
> (Ref: http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg02604.html),
> generating cpu_index this way will not work for PowerPC.
> This patch changes the way cpu_index is handed out by maintaining
> a bit map of the CPUs that tracks both addition and removal of CPUs.
> The CPU bitmap allocation logic is part of cpu_exec_init() which is
> called by instance_init routines of various CPU targets. Newly added
> cpu_exec_exit() API handles the deallocation part and this routine is
> called from generic CPU::instance_finalize().
> Note: This new CPU enumeration is for !CONFIG_USER_ONLY only.
> CONFIG_USER_ONLY continues to have the old enumeration logic.
> Signed-off-by: Bharata B Rao <address@hidden>
> Reviewed-by: Eduardo Habkost <address@hidden>

Reviewed-by: David Gibson <address@hidden>

David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!

Attachment: pgpBsAFmfl7R3.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]