From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] xen/apic: implement io apic read with hypercall Date: Thu, 26 Apr 2012 11:33:46 -0400 Message-ID: <20120426153346.GC26830@phenom.dumpdata.com> References: <1334913957.2863.1.camel@hp6530s> <4F913340.4000202@citrix.com> <1334920396.2863.16.camel@hp6530s> <1334925508.28331.63.camel@zakaz.uk.xensource.com> <20120420164150.GC31062@phenom.dumpdata.com> <20120423151123.GC24481@phenom.dumpdata.com> <20120424162321.GH3213@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Lin Ming Cc: Andrew Cooper , "xen-devel@lists.xensource.com" , Ian Campbell , "linux-kernel@vger.kernel.org" List-Id: xen-devel@lists.xenproject.org > >> > >> unsigned int xen_io_apic_read(unsigned apic, unsigned reg) > >> { > >> =A0 =A0 =A0 =A0 struct physdev_apic apic_op; > >> =A0 =A0 =A0 =A0 int ret; > >> > >> =A0 =A0 =A0 =A0 apic_op.apic_physbase =3D mpc_ioapic_addr(apic); > >> =A0 =A0 =A0 =A0 apic_op.reg =3D reg; > >> =A0 =A0 =A0 =A0 ret =3D HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &ap= ic_op); > >> =A0 =A0 =A0 =A0 if (!ret) > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic_op.value; > >> > >> =A0 =A0 =A0 =A0 /* emulate register */ > >> =A0 =A0 =A0 =A0 if (reg =3D=3D 0x1) > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0x00170020; > >> =A0 =A0 =A0 =A0 else if (reg =3D=3D 0x0) > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return apic << 24; > >> =A0 =A0 =A0 =A0 else > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1; > > > > =A0 =A0 =A0 =A0return 0xfd; > = > Where does this magic number 0xfd come from? > = > Both native_io_apic_read and xen_io_apic_read does not return 0xfd on err= or. That is correct. But that is what it should have been. Suresh pointed that out sometime and I managed to lose that part in one of the commits. The earlier patch of this version did that. Thought thinking about it this some I am not sure if 0xff is a better choice... In the end it probably does not matter the slighest.