From: Glauber Costa <glommer@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, avi@redhat.com
Subject: Re: [PATCH] disable interrupt shadow state for emulated instruction
Date: Wed, 8 Apr 2009 15:31:10 -0300 [thread overview]
Message-ID: <20090408183110.GD25323@poweredge.glommer> (raw)
In-Reply-To: <49DCE9E5.8020703@zytor.com>
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.
next prev parent reply other threads:[~2009-04-08 18:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 17:57 [PATCH] disable interrupt shadow state for emulated instruction Glauber Costa
2009-04-08 18:16 ` H. Peter Anvin
2009-04-08 18:31 ` Glauber Costa [this message]
2009-04-08 18:31 ` H. Peter Anvin
2009-04-08 18:43 ` Glauber Costa
2009-04-08 19:45 ` Gleb Natapov
2009-04-09 7:41 ` Avi Kivity
2009-04-09 7:41 ` Avi Kivity
2009-04-09 7:39 ` Avi Kivity
2009-04-08 19:48 ` Gleb Natapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090408183110.GD25323@poweredge.glommer \
--to=glommer@redhat.com \
--cc=avi@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox