From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH 04/18] PVH xen: add params to read_segment_register Date: Mon, 10 Jun 2013 16:10:37 -0700 Message-ID: <20130610161037.06f11c23@mantra.us.oracle.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> <51B5A40102000078000DC8D1@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51B5A40102000078000DC8D1@nat28.tlf.novell.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: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Mon, 10 Jun 2013 09:01:37 +0100 "Jan Beulich" wrote: > >>> 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... I realized the day after that I should have clarified. CS is the only one needed for most of the intercepts, mostly in guest_kernel_mode. So that is a good one to just read always. I moved read_vmcs_selectors back to vmxit_io_instr() which is where it was originally. I went thru all the intercepts to make sure it was not needed anywhere else. thanks Mukesh