>>> On 13.08.18 at 21:17, wrote:
> On 8/13/18 4:45 PM, Razvan Cojocaru wrote:
>> On 8/13/18 4:38 PM, Jan Beulich wrote:
>> On 13.08.18 at 15:19, wrote:
On 8/13/18 3:58 PM, Jan Beulich wrote:
On 13.08.18 at 14:51, wrote:
>> So first we've got that vmx_idtv_reinject() call wr
On 8/13/18 4:45 PM, Razvan Cojocaru wrote:
> On 8/13/18 4:38 PM, Jan Beulich wrote:
> On 13.08.18 at 15:19, wrote:
>>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>>> On 13.08.18 at 14:51, wrote:
> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
> then we emulate
On 8/13/18 4:38 PM, Jan Beulich wrote:
On 13.08.18 at 15:19, wrote:
>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>> On 13.08.18 at 14:51, wrote:
So first we've got that vmx_idtv_reinject() call writing to the VMCS,
then we emulate a CLI, then the failed vmentry. I can't tell if th
On 8/13/18 4:38 PM, Jan Beulich wrote:
On 13.08.18 at 15:19, wrote:
>> On 8/13/18 3:58 PM, Jan Beulich wrote:
>> On 13.08.18 at 14:51, wrote:
So first we've got that vmx_idtv_reinject() call writing to the VMCS,
then we emulate a CLI, then the failed vmentry. I can't tell if th
>>> On 13.08.18 at 15:19, wrote:
> On 8/13/18 3:58 PM, Jan Beulich wrote:
> On 13.08.18 at 14:51, wrote:
>>> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
>>> then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
>>> ran first and then an interrupt po
On 8/13/18 3:58 PM, Jan Beulich wrote:
On 13.08.18 at 14:51, wrote:
>> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
>> then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
>> ran first and then an interrupt popped up, or if an interrupt had
>> alrea
>>> On 13.08.18 at 14:51, wrote:
> So first we've got that vmx_idtv_reinject() call writing to the VMCS,
> then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
> ran first and then an interrupt popped up, or if an interrupt had
> already been __vmwrit()ten and then CLI caused th
On 8/13/18 3:22 PM, Jan Beulich wrote:
On 13.08.18 at 13:55, wrote:
>> On 8/9/18 11:35 AM, Jan Beulich wrote:
>> On 09.08.18 at 10:20, wrote:
On 8/9/18 10:54 AM, Jan Beulich wrote:
On 08.08.18 at 16:26, wrote:
>> 1. Is it possible to already have a valid interrupt writ
>>> On 13.08.18 at 13:55, wrote:
> On 8/9/18 11:35 AM, Jan Beulich wrote:
> On 09.08.18 at 10:20, wrote:
>>> On 8/9/18 10:54 AM, Jan Beulich wrote:
>>> On 08.08.18 at 16:26, wrote:
> 1. Is it possible to already have a valid interrupt written in
> VM_ENTRY_INTR_INFO at EXIT_REASO
On 8/9/18 11:35 AM, Jan Beulich wrote:
On 09.08.18 at 10:20, wrote:
>> On 8/9/18 10:54 AM, Jan Beulich wrote:
>> On 08.08.18 at 16:26, wrote:
1. Is it possible to already have a valid interrupt written in
VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
vmx_vmexit_h
>>> On 09.08.18 at 10:20, wrote:
> On 8/9/18 10:54 AM, Jan Beulich wrote:
> On 08.08.18 at 16:26, wrote:
>>> 1. Is it possible to already have a valid interrupt written in
>>> VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
>>> vmx_vmexit_handler()?
>>
>> You mean right after the exi
On 8/9/18 10:54 AM, Jan Beulich wrote:
On 08.08.18 at 16:26, wrote:
>> 1. Is it possible to already have a valid interrupt written in
>> VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
>> vmx_vmexit_handler()?
>
> You mean right after the exit? Where would that come from? I'm
> afrai
>>> On 08.08.18 at 16:26, wrote:
> 1. Is it possible to already have a valid interrupt written in
> VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
> vmx_vmexit_handler()?
You mean right after the exit? Where would that come from? I'm
afraid I don't see the connection to your issue (or th
> 2. Is it possible that something else in that path writes into
> VM_ENTRY_INTR_INFO (which the vmx_intr_assist() logic can't possibly
> prevent)? For example, in my Xen 4.7.5 sources, there's a
> pt_restore_timer(v); call in hvm_do_resume() before the vm_event
> emulation code.
Actually even han
Hello,
I'm seeing rare occasions where this backtrace occurs at a point in
__vmx_inject_exception() where there's already a valid interrupt set up
in VM_ENTRY_INTR_INFO (that is, once the value is __vmread(), intr_info
& INTR_INFO_VALID_MASK is non-zero):
Xen call trace:
[] vmx.c#__vmx_inject_
15 matches
Mail list logo
