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 08:55:52 +0200 Message-ID: <4FA22BF8.2050409@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="===============4098233777693533906==" 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) --===============4098233777693533906== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE4D7DB7D964CF58A0ADBFBFA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE4D7DB7D964CF58A0ADBFBFA 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? This is in the inline patch Konrad asked me to check. >=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. It does fail but at least for me it seems slightly different. I do the mo= dprobe after turning on all acpi debugging levels and layers. And without any ch= ange there are queries visible. With that patch the driver just fails but ther= e are no queries. I plan to have another go with messages sprinkled to all exit= paths today, too (was just a bit too late and two pints later yesterday). -Stefan >=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) >>>>>> >>>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel >> >=20 >=20 --------------enigE4D7DB7D964CF58A0ADBFBFA 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/ iQIcBAEBCgAGBQJPoiv/AAoJEOhnXe7L7s6j6Z0P/1gvbeEvQMj5VA+TgaDC8yH6 jQ6Z/walWWrge3LCQR8coUo66JSq7yQFy9FQTCEDSPYG4gHJJTicabVtni6aeXkv bjfOWIQcFiUmzzR6/mzDM1CSeZ0ICoRQ8QJOPq7RnEtP2BZOUCD/M3JUOEn8A1rg 06aU6Yw2v2wJNfb3PIgovGnPpu8GMcBbRPS9r9THqVDSis8fK0JRtD6NqtWz5koc uTLapvKP+Fys4qTZeseeAtptnzaR/M8qviJJ+1Upm0XU3Sl6yBF0K/Spczf9HgLT g5neXdz/CfhHqkYtGpphBzZaCS02olrevGRZlAgbo3EtfNiQhqqfFIgbB9cVz3Yb x5zD3tXoqA23w0kVp/zuRnHz7CEm61OSBDgLEsP9TcK0zXZZf24mcxGSyPY6J6py PRdW9ubQeuQQy1ei19we3rRy9A69jHQC6Cw26ZAd/CRhH4taBpWfIYKQlZUJQp+T ZVWN5RJjt7tefGRVFgQEuVdWyl0QlPvqcbEuEkEe2ff5cUBi7OkiJtbyxEzhOBk0 t4sU+OOR6a+t5EkVYGZeq70yViNZEYaMvRxUO6sv/FRj8i6bFZT414nmR0bxmzov 9KzsGKsIGoCcEzEU9za3Vem3LM/0CnijdSqeMsBmdvUwiX8SwQZEua68UtDGPIbx xQuBf7PU9xg2Jzw+gT5V =3DmT -----END PGP SIGNATURE----- --------------enigE4D7DB7D964CF58A0ADBFBFA-- --===============4098233777693533906== 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 --===============4098233777693533906==--