Re: [Xen-devel] [PATCH 04/18] PVH xen: add params to read_segment_register

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Mon, 10 Jun 2013 09:01:37 +0100
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> >>> On 08.06.13 at 02:45, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> >>> wrote:
> > On Fri, 07 Jun 2013 07:29:40 +0100
> > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > 
> >> >>> On 07.06.13 at 03:43, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> >> >>> wrote:
> >> > On Thu, 06 Jun 2013 07:48:49 +0100
> >> > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> >> > 
> >> >> >>> On 06.06.13 at 03:25, Mukesh Rathor
> >> >> >>> <mukesh.rathor@xxxxxxxxxx> wrote:
> >> >> > On Fri, 31 May 2013 11:00:12 +0100
> >> >> > "Jan Beulich" <JBeulich@xxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel