From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [RFC] Genapic in x86_64 Dom0 Date: Mon, 22 Aug 2005 19:48:24 +0100 Message-ID: References: <20050822182036.GV7762@shell0.pdx.osdl.net> Return-path: In-Reply-To: Your message of "Mon, 22 Aug 2005 11:20:36 PDT." <20050822182036.GV7762@shell0.pdx.osdl.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Chris Wright Cc: xen-devel@lists.xensource.com, "Puthiyaparambil, Aravindh" List-Id: xen-devel@lists.xenproject.org > * Keir Fraser (Keir.Fraser@cl.cam.ac.uk) wrote: > > Perhaps genapic_xen is currently being too smart for its own good? :-) > > Hehe, quite possible ;-) > > > On i386 we lobotomised local apic handling. > > My goal was to avoid (equivalent of) #if 0 where possible, by backfilling > functionality where possible. I also had filled out mpc_config_processor > during mp_register_lapic and tried to maintain the physid map (that bit > isn't merged). Do you think there's value in maintaining that level of > code compatibility? I suspect we might be best off just diverging completely and having our own file that implements enough of the local APIC "interface" to get everything else to build, but is basically a set of no-ops. That's basically what we have for arch/xen/i386. Maintaining processor and lapic info is pretty pointless since those things aren't under domain 0's control, although it may be as easy to do so as not. -- Keir