From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 04/18] PVH xen: add params to read_segment_register Date: Mon, 10 Jun 2013 09:01:37 +0100 Message-ID: <51B5A40102000078000DC8D1@nat28.tlf.novell.com> References: <1369445137-19755-1-git-send-email-mukesh.rathor@oracle.com> <1369445137-19755-5-git-send-email-mukesh.rathor@oracle.com> <51A890CC02000078000D9F56@nat28.tlf.novell.com> <20130605182546.7c1ca5c5@mantra.us.oracle.com> <51B04CF102000078000DBC3D@nat28.tlf.novell.com> <20130606184328.0d56b3ae@mantra.us.oracle.com> <51B199F402000078000DC1CF@nat28.tlf.novell.com> <20130607174537.0c3ce217@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130607174537.0c3ce217@mantra.us.oracle.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mukesh Rathor Cc: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 08.06.13 at 02:45, Mukesh Rathor wrote: > On Fri, 07 Jun 2013 07:29:40 +0100 > "Jan Beulich" wrote: > >> >>> On 07.06.13 at 03:43, Mukesh Rathor >> >>> wrote: >> > On Thu, 06 Jun 2013 07:48:49 +0100 >> > "Jan Beulich" wrote: >> > >> >> >>> On 06.06.13 at 03:25, Mukesh Rathor >> >> >>> wrote: >> >> > On Fri, 31 May 2013 11:00:12 +0100 >> >> > "Jan Beulich" wrote: >> >> > > ........ >> And anything we leave there should be optimized to hide latencies >> between dependent instructions (the worst example here likely is >> the CR2 read followed immediately by the intermediate register >> getting written to memory, even though the control register read >> could be done almost first thing in the handler). >> >> One question though is why HVM code gets away without always >> filling those fields, but PVH code doesn't. Could you say a word >> on this? > > Yeah, sure. The HVM IO instr emulation goes thru handle_mmio/handle_pio, > and I've not looked at them since the PVH goes thru emulate_privileged_op(), > which calls read_segment_register macro. The HVM functions do not call > the read_segment_register macro. Then is there any reason why, rather than always reading all selector registers, you couldn't defer the reading to when this macro actually gets used? I'd assume there are going to be many exits that don't need any of them... Jan