From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Workings/effectiveness of the xen-acpi-processor driver Date: Thu, 03 May 2012 14:58:02 +0200 Message-ID: <4FA280DA.9080505@canonical.com> References: <4F97F58A.8090409@canonical.com> <20120426155033.GE26830@phenom.dumpdata.com> <4F9976F8.8040502@canonical.com> <20120501200207.GA15313@phenom.dumpdata.com> <4FA06541.7050607@amd.com> <4FA14C2C.5030104@canonical.com> <20120502160812.GA6611@phenom.dumpdata.com> <4FA1699A.9070405@amd.com> <20120502171415.GA17477@phenom.dumpdata.com> <4FA1A79B.5040701@amd.com> <20120502214147.GA7670@phenom.dumpdata.com> <4FA1B096.5010009@amd.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7483904360065399984==" Return-path: In-Reply-To: <4FA1B096.5010009@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: "xen-devel@lists.xensource.com" , Jan Beulich , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7483904360065399984== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC439D14FE923CC3E0AE06D48" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC439D14FE923CC3E0AE06D48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03.05.2012 00:09, Boris Ostrovsky wrote: > On 05/02/2012 05:41 PM, Konrad Rzeszutek Wilk wrote: >> On Wed, May 02, 2012 at 02:31:07PM -0700, Boris Ostrovsky wrote: >>> On 05/02/2012 01:14 PM, Konrad Rzeszutek Wilk wrote: >>>> On Wed, May 02, 2012 at 01:06:34PM -0400, Boris Ostrovsky wrote: >>>>> On 05/02/2012 12:08 PM, Konrad Rzeszutek Wilk wrote: >>>>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>>>> index a8f8844..d816448 100644 >>>>>> --- a/arch/x86/xen/enlighten.c >>>>>> +++ b/arch/x86/xen/enlighten.c >>>>>> @@ -811,7 +811,29 @@ static void xen_io_delay(void) >>>>>> #ifdef CONFIG_X86_LOCAL_APIC >>>>>> static u32 xen_apic_read(u32 reg) >>>>>> { >>>>>> - return 0; >>>>>> + struct xen_platform_op op =3D { >>>>>> + .cmd =3D XENPF_get_cpuinfo, >>>>>> + .interface_version =3D XENPF_INTERFACE_VERSION, >>>>>> + .u.pcpu_info.xen_cpuid =3D 0, >>>>> >>>>> >>>>> Is this always zero? This will probably solve the current problem >>>> >>>> Its a CPU number (not tied in to APIC or ACPI IDs). >>> >>> Why not use CPU number instead of zero here? >> >> The issue was only with the bootup CPU - so was using the Xen's >> bootup CPU number - which is zero (as is Linux's). >=20 > I agree that for this particular problem this may be sufficient. >=20 > My concern is that in the future someone may decide to use apic_read(AP= IC_ID) or > read_apic_id() for some other purpose and they won't get expected resul= t (i.e. > on all CPUs they will get the same answer). >=20 >> >>> >>>> >>>>> but I am wondering whether in the future we might hit another bug >>>>> because this routine will return the same APICID for all VCPUs. >>>> >>>> Later on it does a check for 'smp_processor_id()' - and if >>>> that is anything but zero it will bail out. >>> >>> Can you point me to the check you are referring to? >> >> if (!xen_initial_domain() || smp_processor_id()) >=20 > I don't see this line --- neither in the mainline nor in your kernel. W= hich > kernel and which routine is this in? >=20 > BTW, this patch doesn't quite work, xen-acpi-processor driver fails to = load with > the same error as before. I'll look at this tomorrow more carefully. >=20 >=20 > -boris >=20 >> >> >>> >>> -boris >>> >>> >>>> >>>> So this shoudl solve the problem for the bootup processor. >>>>> >>>>> -boris >>>>> >>>>> >>>>>> + }; >>>>>> + int ret =3D 0; >>>>>> + >>>>>> + /* Shouldn't need this as APIC is turned off for PV, and we o= nly >>>>>> + * get called on the bootup processor. But just in case. */ >>>>>> + if (!xen_initial_domain() || smp_processor_id()) >>>>>> + return 0; >>>>>> + >>>>>> + if (reg =3D=3D APIC_LVR) >>>>>> + return 0x10; >>>>>> + >>>>>> + if (reg !=3D APIC_ID) >>>>>> + return 0; >>>>>> + >>>>>> + ret =3D HYPERVISOR_dom0_op(&op); >>>>>> + if (ret) >>>>>> + return 0; >>>>>> + >>>>>> + return op.u.pcpu_info.apic_id; >>>>>> } >>>>>> >>>>>> static void xen_apic_write(u32 reg, u32 val) I added debugging to all exit paths that could return 0 (which is what th= e boot_cpu_physical_apicid is set to with that patch. Which would only leav= e the case of the HV call returning the wrong value somehow... >>>>>> >>>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >=20 >=20 >=20 > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --------------enigC439D14FE923CC3E0AE06D48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPooDaAAoJEOhnXe7L7s6jqgYQAINa5QM4Mko8dQqD0gUMSxwf +GZdh31C3o/yY1z9lIIFSSOqUlgwCHy9+dYv+yrIY1LvcE7tw4XhtAdxCWDDU1fg leB0beMdPK9fbAKx0VWCfiwuZCrwHo+5VT62z/PQ3M2/LQVaoTXWBEQDRtntEzXY i0LqTjPFcBN0EVGhnCXFkqO0+P5XWseTwnh2/6o+iKlaTAzI2/M+ntx27h7w3Pgl nox25mxXCrHGkE+7s5LsbD/C5rMmZuhk8CNst7aG9Xm3fMcPn2KtnGjt/uK4tNSU BA8hcStTJoD42dF3kqYIDMvnpc3OSdptcMgbsS3Wo2zCC83kf8OgKR3RiY9F1hiE CpjEHfMLJQyGV10qe9uAC5oZnonpMAtUSlgKZsXmyCtqlbT/HOy/lkXAuLnsnaf1 q8S7c5mtCHlkN6r+zVzjNZoTCVxRWvHkol5Nbix2IRNENeUvPgF3x1xfya9ymQhT hNjwkZakjt9CFjoLsfD7QFZ0nN5HQQy0Txp5k3tSKc6croSWS2/CLM/hRMec563/ xcFVlxgv8MIRNJtMsWfTnJY9FZBzCVbRuKPOy72b9yuzrueJBwpq9Bcfw04FpAiB /NNUZnhIVicMizUUdC+/62d+9627FRvz7fF8paOwSVqY31GHf1535C5NZsfcF47x foNqJfqdOMpoUh/9sea6 =FQCk -----END PGP SIGNATURE----- --------------enigC439D14FE923CC3E0AE06D48-- --===============7483904360065399984== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7483904360065399984==--