Re: [PATCH] disable interrupt shadow state for emulated instruction

[Glauber Costa]

On Wed, Apr 08, 2009 at 11:16:05AM -0700, H. Peter Anvin wrote:
> Glauber Costa wrote:
>> we currently unblock shadow interrupt state when we skip an instruction,
>> but failing to do so when we actually emulate one. This blocks interrupts
>> in key instruction blocks, in particular sti; hlt; sequences
>>
>> Without this patch, I cannot boot gpxe option roms at vmx machines.
>> This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index c6997c0..cee38e4 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -736,26 +736,34 @@ static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
>>  	vmcs_writel(GUEST_RFLAGS, rflags);
>>  }
>>  +static void vmx_block_interrupt_shadow(struct kvm_vcpu *vcpu)
>> +{
>> +	/*
>> +	 * We emulated an instruction, so temporary interrupt blocking
>> +	 * should be removed, if set.
>> +	 */
>> +	u32 interruptibility = vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
>> +	u32 interruptibility_mask = ((GUEST_INTR_STATE_STI | GUEST_INTR_STATE_MOV_SS));
>> +
>> +	if (interruptibility & interruptibility_mask)
>> +		vmcs_write32(GUEST_INTERRUPTIBILITY_INFO,
>> +			     interruptibility & ~interruptibility_mask);
>> +	vcpu->arch.interrupt_window_open = 1;
>> +}
>> +
>
> How does this logic work when the instruction emulated is an STI or MOV  
> SS instruction?  In particular, when does GUEST_INTERRUPTIBILITY_INFO  
> sets set to reflect the *blocking* operation?
mov ss is a non-issue, since it is executed natively.

As for sti, I'm not sure. I see code for emulating sti, but in my testings,
this code was never ever touched, under a number of different scenarios.
Avi, can you clarify if sti can be in fact emulated, and under which
circunstamces? 

If it can, I'd say we'd have to introduce a block_interrupt_shadow as well,
and call from it from within the emulator, whenever the first sti is dispatched.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/