From: Jason Wang <jasowang@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] virtio 1 issues
Date: Mon, 10 Aug 2015 14:22:07 +0800 [thread overview]
Message-ID: <55C8430F.90505@redhat.com> (raw)
In-Reply-To: <20150807124942.6c127a6b.cornelia.huck@de.ibm.com>
On 08/07/2015 06:49 PM, Cornelia Huck wrote:
> On Fri, 07 Aug 2015 13:07:35 +0800
> Jason Wang <jasowang@redhat.com> 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.
next prev parent reply other threads:[~2015-08-10 6:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-06 22:31 [Qemu-devel] virtio 1 issues Michael S. Tsirkin
2015-08-07 5:07 ` Jason Wang
2015-08-07 10:49 ` Cornelia Huck
2015-08-10 6:22 ` Jason Wang [this message]
2015-08-10 15:32 ` Cornelia Huck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55C8430F.90505@redhat.com \
--to=jasowang@redhat.com \
--cc=cornelia.huck@de.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).