>>> On 07.11.16 at 13:27, <rcojoc...@bitdefender.com> wrote:
> On 11/07/2016 02:23 PM, Jan Beulich wrote:
>>> At this point it looks like the best solution is to simply discard the
>>> > non-architectural event if there's a pending architectural one, and add
>>> > a new vm_event, as suggested by Tamas, that notifies the application
>>> > that a trap has failed, or succeeded, and let it do the best it can with
>>> > that information.
>> Well, if the two of you think this is something which fits into the VM
>> event model, then I guess that's an option. I, for one, am not
>> convinced: It simply seems too special purpose. If this was a more
>> generic event ("interruption delivered", perhaps with a type or
>> vector qualifier) that can be subscribed to, and the app did that
>> only for such transient periods of time, this would look more
>> reasonable to me.
>
> Indeed, that's the way I think of it: the user is free to subscribe to
> the event or not, and the event is:
>
> struct vm_event_injection_result {
> uint32_t vector;
> uint32_t type;
> uint32_t error_code;
> uint64_t cr2;
> uint32_t injected;
> };
>
> with injected 0 for failure and 1 for success. It's as generic as possible.
Wait, no, that's not what I did describe. I'm not talking about the
"result" of an injection (through hypercall), but about delivering of
events (of any origin). Hence there can't be any "failure" here.
IOW what I'm proposing is a "VM is about to see this interruption"
event.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
