On Wed, Jun 14, 2017 at 05:32:12PM +0200, Paolo Bonzini wrote:
>
>
> On 14/06/2017 17:28, Roman Kagan wrote:
> > On Wed, Jun 14, 2017 at 05:08:02PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 06/06/2017 20:19, Roman Kagan wrote:
> >>> +sint_route->msg_status = ret;
> >>> +/* notify the
On 14/06/2017 17:28, Roman Kagan wrote:
> On Wed, Jun 14, 2017 at 05:08:02PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 06/06/2017 20:19, Roman Kagan wrote:
>>> +sint_route->msg_status = ret;
>>> +/* notify the msg originator of the progress made; if the slot was
>>> busy we
>>> + * set
On Wed, Jun 14, 2017 at 05:08:02PM +0200, Paolo Bonzini wrote:
>
>
> On 06/06/2017 20:19, Roman Kagan wrote:
> > +sint_route->msg_status = ret;
> > +/* notify the msg originator of the progress made; if the slot was
> > busy we
> > + * set msg_pending flag in it so it will be the gue
On 06/06/2017 20:19, Roman Kagan wrote:
> +sint_route->msg_status = ret;
> +/* notify the msg originator of the progress made; if the slot was busy
> we
> + * set msg_pending flag in it so it will be the guest who will do EOM and
> + * trigger the notification from KVM via sint_a
Add infrastructure to deliver SynIC messages to the guest SynIC message
page.
Note that KVM also may want to deliver (SynIC timer) messages to the
same message slot.
The problem is that the access to a SynIC message slot is controlled by
the value of its .msg_type field which indicates if the slo
