Re: [Xen-devel] [PATCH V2] x86/vm_event: block interrupt injection for sync vm_events

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 12/13/18 4:58 PM, Jan Beulich wrote:
>>>> On 13.12.18 at 14:18, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> So, long story short, on VMX we first send out the vm_event, while
>> processing it an interrupt / exception may become pending, before
>> resuming the VCPU that has sent out the vm_event there's a Xen function
>> that picks up the pending interrupt and schedules it (writes it in the
>> VMCS), and only then we attempt the emulation, which may overwrite it
>> (because there's only one place we can write to schedule interrupts /
>> exceptions).
> 
> So perhaps the solution is indeed to change the order of how things
> get done, instead of blocking interrupts? You seem to think this way
> too, as per ...
> 
>> 2. Interrupts are not blocked indefinitely - only until the emulation is
>> done. It could be argued that that's really the proper place for them to
>> be processed anyway - on an instruction boundary, _after_ the
>> in-progress instruction has finished executing. It's just that with the
>> vm_event introspection thing you could say that executing the current
>> instruction may take a bit longer.
> 
> ... this.

Quite possibly, following the lead of the singlestepping code just
seemed like the most straightforward way out of the problem. Of course
an alternative way of handling interrupts would probably be preferrable,
however we'd need a bit of guidance on how to go about it and in the
meantime I don't see how this small fix would hurt.

I remember Andrew suggesting taking something like this on at the Xen
Developer Summit in Budapest but then of course much more important
things happened with Meltdown & al.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel