2010/4/6 Gleb Natapov <g...@redhat.com>:
> On Tue, Apr 06, 2010 at 01:11:23PM +0900, Yoshiaki Tamura wrote:
>> Hi.
>>
>> When handle_io() is called, rip is currently proceeded *before* actually
>> having
>> I/O handled by qemu in userland. Upon implementing Kemari for
>> KVM(http://www.mail-archive.com/kvm@vger.kernel.org/msg25141.html) mainly in
>> userland qemu, we encountered a problem that synchronizing the content of
>> VCPU
>> before handling I/O in qemu is too late because rip is already proceeded in
>> KVM,
>> Although we avoided this issue with temporal hack, I would like to ask a few
>> question on skip_emulated_instructions.
>>
>> 1. Does rip need to be proceeded before having I/O handled by qemu?
> In current kvm.git rip is proceeded before I/O is handled by qemu only
> in case of "out" instruction. From architecture point of view I think
> it's OK since on real HW you can't guaranty that I/O will take effect
> before instruction pointer is advanced. It is done like that because we
> want "out" emulation to be real fast so we skip x86 emulator.
Thanks for your reply.
If proceeding rip later doesn't break the behavior of devices or
introduce slow down, I would like that to be done.
>> 2. If no, is it possible to divide skip_emulated_instructions(), like
>> rec_emulated_instructions() to remember to next_rip, and
>> skip_emulated_instructions() to actually proceed the rip.
> Currently only emulator can call userspace to do I/O, so after
> userspace returns after I/O exit, control is handled back to emulator
> unconditionally. "out" instruction skips emulator, but there is nothing
> to do after userspace returns, so regular cpu loop is executed. If we
> want to advance rip only after userspace executed I/O done by "out" we
> need to distinguish who requested I/O (emulator or kvm_fast_pio_out())
> and call different code depending on who that was. It can be done by
> having a callback that (if not null) is called on return from userspace.
Your suggestion is to introduce a callback entry, and instead of
calling kvm_rip_write(), set it to the entry before calling
kvm_fast_pio_out(),
and check the entry upon return from the userspace, correct?
According to the comment in x86.c, when it was "out" instruction
vcpu->arch.pio.count is set to 0 to skip the emulator.
To call kvm_fast_pio_out(), "!string" and "!in" must be set.
If we can check, vcpu->arch.pio.count, "string" and "in" on return
from the userspace, can't we distinguish who requested I/O, emulator
or kvm_fast_pio_out()?
>> 3. svm has next_rip but when it is 0, nop is emulated. Can this be modified
>> to
>> continue without emulating nop when next_rip is 0?
>>
> I don't see where nop is emulated if next_rip is 0. As far as I see in
> case of next_rip==0 an instruction at rip is decoded to figure out its
> length and then rip is advanced by instruction length. Anyway next_rip
> is svm thing only.
Sorry. I wasn't understanding the code enough.
static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
{
...
if (!svm->next_rip) {
if (emulate_instruction(vcpu, 0, 0, EMULTYPE_SKIP) !=
EMULATE_DONE)
printk(KERN_DEBUG "%s: NOP\n", __func__);
return;
}
Since the printk says NOP, I thought emulate_instruction was doing so...
The reason I asked about next_rip is because I was hoping to use this
entry to advance rip only after userspace executed I/O done by "out",
like if next_rip is !0,
call kvm_rip_write(), and introduce next_rip to vmx if it is usable
because vmx is
currently using local variable rip.
Yoshi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
