On 19/02/18 15:32, Andre Przywara wrote:
Hi,
Hi Andre,
On 16/02/18 17:16, Julien Grall wrote:
On 09/02/18 14:39, Andre Przywara wrote:
+
+ /* Loop over all IRQs affected by this read */
+ for ( i = 0; i < len * 8; i++ )
+ {
+ struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid
+ i);
+
+ if ( irq_is_pending(irq) )
+ value |= (1U << i);
Don't you need to propagate the value to the hardware for virtual
interrupt mapped to physical interrupt?
Do you mean in the write functions below? (This is the read function, I
don't see how this would apply here.)
Hmmm yes. Sorry I misplaced the comment.
In case you meant the write_[cs]pending() functions:
I don't think this makes too much sense. Why would you want to trigger
an hardware IRQ? All you want it is to deliver it to the guest, which is
what those functions below do. So what do I miss here?
Imagine you clear the pending bit on an hardware mapped interrupt. If
you never clear the active bit on the physical one, you will never
receive that interrupt again.
For setting pending bit, I am not entirely sure. But it looks like KVM
is doing it (see latest master). So I am wondering why Xen is diverging
here.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
