Re: [PATCH 22/24] KVM: x86 emulator: restart string instruction without going back to a guest.

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

 



On Thu, Mar 11, 2010 at 06:58:14PM +0900, Takuya Yoshikawa wrote:
> Gleb Natapov wrote:
> >On Wed, Mar 10, 2010 at 07:08:31PM +0900, Takuya Yoshikawa wrote:
> >>Gleb Natapov wrote:
> >>>>>Entering guest from time to time will not change semantics of the
> >>>>>processor (if code is not modified under processor's feet at least).
> >>>>>Currently we reenter guest mode after each iteration of string
> >>>>>instruction for all instruction but ins/outs.
> >>>>>
> >>>>E.g., is there no chance that during the repetitions, in the middle of the
> >>>>repetitions, page faults occur? If it can, without entering the guest, can
> >>>>we handle it?
> >>>>-- I lack some basic assumptions?
> >>>>
> >>>If page fault occurs we inject it to the guest.
> >>>
> >>Oh, I maight fail to tell what I worried about.
> >>Opposite, I mean, I worried about NOT reentering the guest case.
> >>
> >Are you thinking about something specific here? If we inject exceptions
> Yes.
> 
> >when they occur and we inject interrupt when they arrive what problem do
> >you see? I guess this is how real CPU actually works. I doubt it
> >re-reads string instruction on each iteration.
> 
> No problem if we detect and inject page faults like that.
> 
Yes, that part is missing from my patch.

> I just didn't so certain that when we encounter a page fault in the middle
> of the repetitions(about rep specific case), if we can inject it, suspend the
> repetition and enter the guest immediately like SDM Vol.2B says:
> 
>  "A repeating string operation can be suspended by an exception or interrupt.
>   When this happens, the state of the registers is preserved to allow the string
>   operation to be resumed upon a return from the exception or interrupt handler.
>   ...
>   This mechanism allows long string operations to proceed without affecting the
>   interrupt response time of the system."
> 
> Ah, I might misunderstand that if we reenter the guest every time for rep,
> page fault detection, not injection, can be done by the other ways easily,
> by EXIT reason or something. Both ways may need the same thing, sorry.
When instruction is emulated page fault detection is done by the
emulator itself. During guest entry the exception is injected. So all we
need to do in the emulator is to enter guest immediately when exception
condition is detected.

> 
> Another concern I wrote was just about the dependencies between your
> "time to time" criteria and SDM's "without affecting the interrupt response time".
> This is just the problem of how we can determine the criteria appropriately.
> 
We can reenter guest immediately if there is pending interrupt (we can't
do that with ins read ahead, but this optimization is non architectural anyway).

> >>I know that current implementation with reentrance is OK.
> >Current implementation does not reenter guest on each iteration for pio
> >string, so currently we have both variants.
> 
> I'm sorry, I was confused as if the current implementation already
> included some of your patches.
> 
It's independent from my patches. This is how string pio always worked.
Otherwise certain workloads are too slow.

> >
> >>To inject a page fault without reentering the guest, we need to add
> >>some more hacks to the emulator IIUC.
> >>
> >No, we just need to enter guest if exception happens. I see that this in
> >handled incorrectly in my current patch series.
> 
> I was just not certain if the following condition(from SDM Vol.2B) is satisfied
> 
>   "The source and destination registers point to the next string elements
>    to be operated on, the EIP register points to the string instruction,
>    and the ECX register has the value it held following the last successful
>    iteration of the instruction."
It is satisfied. Writeback is done on each iteration.

> 
> in the emulator's fault handling. I should have read your patch more closely.
> 
> Thanks,
>   Takuya

--
			Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux