qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] virtio 1 issues


From: Cornelia Huck
Subject: Re: [Qemu-devel] virtio 1 issues
Date: Mon, 10 Aug 2015 17:32:45 +0200

On Mon, 10 Aug 2015 14:22:07 +0800
Jason Wang <address@hidden> wrote:

> 
> 
> On 08/07/2015 06:49 PM, Cornelia Huck wrote:
> > On Fri, 07 Aug 2015 13:07:35 +0800
> > Jason Wang <address@hidden> wrote:
> >
> >>> 2. ring resizing is broken - it actually has a comment:
> >>>         /* TODO: need a way to put num back on reset. */
> >>> guest that runs out of memory might down-size the ring.
> >>> Afterwards, ring size won't come back up after reset - not nice.
> >>>
> >> Then we need a new field to keep track the original queue size and
> >> migrate this.
> > virtio-ccw neatly sidesteps it by not implementing ring size changes at
> > all :)
> >
> > But it isn't really all good, see
> >
> > /* TODO: Add interface to handle vring.num changing */
> >
> > We either need to implement this or fence off changing the ring size, I
> > guess.
> 
> Yes.
> 
> >>> Given that the modern layout is disabled by default,
> >>> I don't think these are release blockers.
> >>>
> >> Yes and looks like we need a new subsection and transport specific
> >> callbacks to fix above?
> > Agreed, it's not urgent as virtio-1 is not yet the default (and not
> > even enabled for ccw).
> >
> > I'm not sure we need transport-specific callbacks. Shouldn't the core
> > be able to track initial and actual size (and migrate in an optional
> > subsection), as long as the transports use defined interfaces to
> > interact with it?
> >
> 
> For size, I agree it should be tracked by core. But we need also track
> transport specific data like dfselect/gfselect for pci.

Yup. I'll leave pci data to the pci folks :) I have a patch for
handling the size; I'll post it after I've tested it a bit.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]