[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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...

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.