>
> You have to be careful here. Xen will only ever deliver the evtchn
interrupt
> to VCPU0. I can't immediately see anything preventing an HVM domain
trying to
> bind and evtchn to another VCPU but you can see from the code in
> hvm_assert_evtchn_irq() that the guest will only be kicked for events
bound to
> VCPU0 (is_hvm_pv_evtchn_vcpu() will only be true for Linux PVonHVM
domains).
> Thus if you bind your DPC to a CPU other than zero and don't set it to
> HighImportance then it will not be immediately scheduled since default
DPC
> importance is MediumImportance.
>
Are you sure? That's not what I remember seeing. You always have to
query shared_info_area->vcpu_info[0] not
shared_info_area->vcpu_info[vcpu], but the actual VCPU the interrupt is
scheduled onto can be any.
James
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> You have to be careful here. Xen will only ever deliver the evtchn
interrupt
> to VCPU0. I can't immediately see anything preventing an HVM domain
trying to
> bind and evtchn to another VCPU but you can see from the code in
> hvm_assert_evtchn_irq() that the guest will only be kicked for events
bound to
> VCPU0 (is_hvm_pv_evtchn_vcpu() will only be true for Linux PVonHVM
domains).
> Thus if you bind your DPC to a CPU other than zero and don't set it to
> HighImportance then it will not be immediately scheduled since default
DPC
> importance is MediumImportance.
>
Are you sure? That's not what I remember seeing. You always have to
query shared_info_area->vcpu_info[0] not
shared_info_area->vcpu_info[vcpu], but the actual VCPU the interrupt is
scheduled onto can be any.
James
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel