Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266512AbUIOPn3 (ORCPT ); Wed, 15 Sep 2004 11:43:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266498AbUIOPn3 (ORCPT ); Wed, 15 Sep 2004 11:43:29 -0400 Received: from shockwave.systems.pipex.net ([62.241.160.9]:38879 "EHLO shockwave.systems.pipex.net") by vger.kernel.org with ESMTP id S266490AbUIOPnR (ORCPT ); Wed, 15 Sep 2004 11:43:17 -0400 Date: Wed, 15 Sep 2004 16:43:59 +0100 (BST) From: Tigran Aivazian X-X-Sender: tigran@einstein.homenet To: Bill Davidsen Cc: linux-kernel@vger.kernel.org Subject: Re: Latest microcode data from Intel. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1141 Lines: 23 On Wed, 15 Sep 2004, Bill Davidsen wrote: > That's exactly why I mentioned using the per-cpu device if present. While > having CPUs with different loaders is not a feature today, I wouldn't bet > that will always be true. We know that AMD expects to ship dual core CPUs > in an Opteron form factor. If I have a dual opteron system and replace one > CPU with dual core, will I need a different loader? I have no idea, but > since it's easy to use the per-CPU microcode I would. The microcode driver handles the case of different types of CPUs in an SMP system internally. Namely, it selects the appropriate microcode data chunks for each CPU and then uploads them correctly to each one. Anyway, it only works for Intel processors, so AMD is not in the equation anyway (unless I discover that AMD processors support similar feature and enhance the driver to support it). Kind regards Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/