[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xc_hvm_inject_trap() races



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.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.