Rusty Russell wrote:
On Tue, 2007-09-25 at 19:15 +0200, Dor Laor wrote:
At the moment it's not good enough, there is a potential race were the
guest optimistically turn off
the VRING_AVAIL_F_NO_INTERRUPT in the vring_restart and afterwards
finds there are more_used so
it consume them in
Rusty Russell wrote:
On Mon, 2007-09-24 at 15:44 +0200, Dor Laor wrote:
Rusty Russell wrote:
+irqreturn_t vring_interrupt(int irq, void *_vq)
+{
+ struct vring_virtqueue *vq = to_vvq(_vq);
+
+ pr_debug(virtqueue interrupt for %p\n, vq);
+
+ if
On Tue, 2007-09-25 at 19:15 +0200, Dor Laor wrote:
At the moment it's not good enough, there is a potential race were the
guest optimistically turn off
the VRING_AVAIL_F_NO_INTERRUPT in the vring_restart and afterwards
finds there are more_used so
it consume them in the poll function.
If in
These helper routines supply most of the virtqueue_ops for hypervisors
which want to use a ring for virtio. Unlike the previous lguest
implementation:
1) The rings are variable sized (2^n-1 elements).
2) They have an unfortunate limit of 65535 bytes per sg element.
3) The page numbers are always
Rusty Russell wrote:
These helper routines supply most of the virtqueue_ops for hypervisors
which want to use a ring for virtio. Unlike the previous lguest
implementation:
1) The rings are variable sized (2^n-1 elements).
2) They have an unfortunate limit of 65535 bytes per sg element.
3) The
On Mon, 2007-09-24 at 15:44 +0200, Dor Laor wrote:
Seems like there is a problem with shared irq line, the interrupt
handler always returns IRQ_HANDLED (except for the trivial case
were the callback is null).
It can be solved by having a host irq counter (in the shared ring) and
a guest irq
