From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mx.groups.io with SMTP id smtpd.web11.2912.1580798972402649118 for ; Mon, 03 Feb 2020 22:49:32 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.115, mailfrom: liming.gao@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Feb 2020 22:49:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,398,1574150400"; d="scan'208";a="378320960" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga004.jf.intel.com with ESMTP; 03 Feb 2020 22:49:31 -0800 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 3 Feb 2020 22:49:31 -0800 Received: from shsmsx606.ccr.corp.intel.com (10.109.6.216) by SHSMSX605.ccr.corp.intel.com (10.109.6.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 4 Feb 2020 14:49:29 +0800 Received: from shsmsx606.ccr.corp.intel.com ([10.109.6.216]) by SHSMSX606.ccr.corp.intel.com ([10.109.6.216]) with mapi id 15.01.1713.004; Tue, 4 Feb 2020 14:49:29 +0800 From: "Liming Gao" To: "devel@edk2.groups.io" , "anthony.perard@citrix.com" CC: Laszlo Ersek , "Kinney, Michael D" , Ard Biesheuvel , "xen-devel@lists.xenproject.org" , "Justen, Jordan L" , Julien Grall , "Feng, Bob C" Subject: Re: [edk2-devel] [PATCH 2/5] MdePkg: Allow PcdFSBClock to by Dynamic Thread-Topic: [edk2-devel] [PATCH 2/5] MdePkg: Allow PcdFSBClock to by Dynamic Thread-Index: AQHV1r69ewqbWYIeh0aB29LAD6y7HagE2qLwgARAgoCAAB9IAIABZkCg Date: Tue, 4 Feb 2020 06:49:29 +0000 Message-ID: <4792efc4d3634fd98ff85e0501d7a447@intel.com> References: <20200129121235.1814563-1-anthony.perard@citrix.com> <20200129121235.1814563-3-anthony.perard@citrix.com> <20200203153407.GH2306@perard.uk.xensource.com> <20200203172604.GI2306@perard.uk.xensource.com> In-Reply-To: <20200203172604.GI2306@perard.uk.xensource.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action x-originating-ip: [10.239.127.36] MIME-Version: 1.0 Return-Path: liming.gao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your data. Seemly, those data is acceptable on OvmfXen. For this= patch, Reviewed-by: Liming Gao Thanks Liming > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Anthony P= ERARD > Sent: Tuesday, February 4, 2020 1:26 AM > To: Gao, Liming > Cc: Laszlo Ersek ; devel@edk2.groups.io; Kinney, Mich= ael D ; Ard Biesheuvel > ; xen-devel@lists.xenproject.org; Justen, Jor= dan L ; Julien Grall > ; Feng, Bob C > Subject: Re: [edk2-devel] [PATCH 2/5] MdePkg: Allow PcdFSBClock to by Dy= namic >=20 > On Mon, Feb 03, 2020 at 03:34:07PM +0000, Anthony PERARD wrote: > > On Mon, Feb 03, 2020 at 01:34:55AM +0000, Gao, Liming wrote: > > > Anthony: > > > This change is OK to me. But if this PCD is configured as Dynamic,= its value will be got from PCD service. This operation will take > some time and cause the inaccurate time delay. Have you measured its imp= act? > > > > No, I haven't. But I don't think it matter in a Xen guest, the APIC ti= mer is > > emulated anyway, so reading from a register of the APIC is going to be > > slower than getting the value from the PCD services, I think. > > (Hopefully, I'm not too wrong.) > > > > But I'll give it at measuring the difference, it would be interesting = to > > know. >=20 > Now that I've given a try, having the value as Dynamic doesn't change > anything in a Xen guest. >=20 > On my test machine, simply running GetPerformanceCounter (); takes > between 10000 ns and 20000 ns. Reading the dynamic value from PCD on the > other hand takes about 350ns. (10ns if it's static.) >=20 > When I run NanoSecondDelay() with different values, I have: > - with static pcd: > 63894 ns to delay by 1 ns > 66611 ns to delay by 10 ns > 43927 ns to delay by 100 ns > 71367 ns to delay by 1000 ns > 55881 ns to delay by 10000 ns > 147716 ns to delay by 100000 ns > 1048335 ns to delay by 1000000 ns > 10041179 ns to delay by 10000000 ns > - with a dynamic pcd: > 40949 ns to delay by 1 ns > 84832 ns to delay by 10 ns > 82745 ns to delay by 100 ns > 59848 ns to delay by 1000 ns > 52647 ns to delay by 10000 ns > 137051 ns to delay by 100000 ns > 1042492 ns to delay by 1000000 ns > 10036306 ns to delay by 10000000 ns >=20 > So, the kind of PCD used for PcdFSBClock on Xen (with OvmfXen) doesn't > really matter. >=20 > Anyway, thanks for the feedback. >=20 > -- > Anthony PERARD >=20 >=20