On Mon, Jan 8, 2018 at 8:05 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 04.01.18 at 14:06, <wei.l...@citrix.com> wrote:
>> From: Roger Pau Monne <roger....@citrix.com>
>>
>> Note that the unmask and the virq operations are handled by the shim
>> itself, and that FIFO event channels are not exposed to the guest.
>>
>> Signed-off-by: Anthony Liguori <aligu...@amazon.com>
>> Signed-off-by: Roger Pau Monné <roger....@citrix.com>
>> Signed-off-by: Sergey Dyasli <sergey.dya...@citrix.com>
>
> In RFC state this certainly doesn't matter yet, but generally I'd
> expect From: to match the first S-o-b.
>
>> @@ -155,11 +156,31 @@ static void set_vcpu_id(void)
>> static void xen_evtchn_upcall(struct cpu_user_regs *regs)
>> {
>> struct vcpu_info *vcpu_info = this_cpu(vcpu_info);
>> + unsigned long pending;
>>
>> vcpu_info->evtchn_upcall_pending = 0;
>> - xchg(&vcpu_info->evtchn_pending_sel, 0);
>> + pending = xchg(&vcpu_info->evtchn_pending_sel, 0);
>>
>> - pv_console_rx(regs);
>> + while ( pending )
>> + {
>> + unsigned int l1 = ffsl(pending) - 1;
>
> find_first_set_bit() would look to be the better match here (and
> below), not the least because it translates (on capable hardware)
> to TZCNT instead of BSF.
>
>> + unsigned long evtchn = xchg(&XEN_shared_info->evtchn_pending[l1],
>> 0);
>> +
>> + __clear_bit(l1, &pending);
>> + evtchn &= ~XEN_shared_info->evtchn_mask[l1];
>> + while ( evtchn )
>> + {
>> + unsigned int port = ffsl(evtchn) - 1;
>> +
>> + __clear_bit(port, &evtchn);
>> + port += l1 * BITS_PER_LONG;
>
> What about a 32-bit client? If that's not intended to be supported,
> building of such a guest should be prevented (in dom0_build.c).
Note that we discarded this approach in the Vixen series because it
wasn't working reliably for injecting remote event channel
notifications.
Regards,
Anthony Liguori
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
