On (Tue) Oct 05 2010 [17:23:19], Michael S. Tsirkin wrote:
> On Tue, Oct 05, 2010 at 07:15:31PM +0530, Amit Shah wrote:
> > > > +
> > > > + spin_lock_irqsave(&vp_dev->lock, flags);
> > > > + list_for_each_entry(info, &vp_dev->virtqueues, node) {
> > > > + /* Select the queue we're interested in */
> > > > + iowrite16(info->queue_index,
> > > > + vp_dev->ioaddr + VIRTIO_PCI_QUEUE_SEL);
> > > > +
> > > > + /* Update the last idx we sent data in */
> > > > + iowrite16(virtqueue_get_avail_idx(info->vq),
> > > > + vp_dev->ioaddr + VIRTIO_PCI_AVAIL_IDX);
> > >
> > > Interesting. Could we just reset the ring instead?
> > > I think this would also solve the qemu problem you
> > > outline, won't it?
> >
> > The problem here is qemu doesn't "know" we went into suspend and came
> > out of it. When going to suspend, qemu could've received a kick
> > notification and would've been just about to process some queue entries.
> > Now when we resume and reset the ring, qemu could crash anyway seeing
> > invalid index values.
>
> Hmm, I don't completely understand this. When there's a reset I expect
> this to discard any previous kicks. No?
I'm talking of a situation like this:
Guest Host
virtqueue_add_buf()
virtqueue_kick()
virtqueue_pop() (in progress)
--> suspend
Now there will be some buffers in the virtqueue but the host wouldn't
know on the next resume. So we want to keep the ring state in the
current state so that the host continues consuming from where it left
off.
Now this wouldn't crash on resume for virtio-net, but for virtio-serial
(which uses chardevs) and also for virtio-block, I guess there are more
problems.
For example, for virtio-serial, if the machine is re-started with a
chardev connected, the virtqueue_num_heads() function gets called, which
results in the 'Guest moved used index' message.
Amit
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
