qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, laine@redhat.com, lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections
Date: Mon, 20 Oct 2014 13:29:44 +0200	[thread overview]
Message-ID: <20141020112943.GG3585@noname.redhat.com> (raw)
In-Reply-To: <1413359710-2799-1-git-send-email-quintela@redhat.com>

Am 15.10.2014 um 09:55 hat Juan Quintela geschrieben:
> Hi
> 
> by popular demand, and after too many time, this series.  This is an
> RFC to know what people think about how to use them, the interface
> proposed, whatever.
> [...]
> 
> Kevin: You asked for optional sections in the past for the block
>    layer, would this proposal be enough for you?

I know I've asked in more than one occasion, and of course I don't
remember all the details any more. Anyway, I remember two cases offhand:

* qcow2 with patches like Delayed COW keeps internal block layer state
  in memory that might need to be migrated. This series looks fine for
  this case in principle, we'd just need to find a way to distinguish
  the affected BlockDriverStates. We can probably take a node-name if it
  exists (with Jeff's auto-naming patches not a problem, because then it
  would always exist)

  How do devices solve this? Do they use something like a qdev path to
  identify to which device a given section belongs?

* When a VM is stopped after an I/O error, we need to migrate the
  information about pending requests (bdrv_drain_all doesn't complete
  the failed requests). Currently we do this in device code, but it
  would be very nice to make this common block layer functionality.

  The problem here is that bdrv_aio_readv/writev get an opaque pointer
  back to the device, which of course becomes meaningless during
  migration.

  So this one is tricky even if we have optional top-level sections.

Kevin

      parent reply	other threads:[~2014-10-20 11:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-15  7:55 [Qemu-devel] [RFC 0/7] Optional toplevel sections Juan Quintela
2014-10-15  7:55 ` [Qemu-devel] [PATCH 1/7] migration: Create optional sections Juan Quintela
2014-10-15  7:55 ` [Qemu-devel] [PATCH 2/7] runstate: Add runstate store Juan Quintela
2014-10-20 10:24   ` Dr. David Alan Gilbert
2014-10-20 10:52     ` Juan Quintela
2014-10-20 15:18       ` Eric Blake
2014-10-22 11:18         ` Dr. David Alan Gilbert
2014-10-22 11:40           ` Markus Armbruster
2014-10-22 15:52             ` Eric Blake
2014-10-15  7:55 ` [Qemu-devel] [PATCH 3/7] runstate: create runstate_index function Juan Quintela
2014-10-15  7:55 ` [Qemu-devel] [PATCH 4/7] runstate: migration allows more transitions now Juan Quintela
2014-10-15 14:42   ` Eric Blake
2014-10-15 15:50     ` Juan Quintela
2014-11-03 12:46   ` Amit Shah
2014-10-15  7:55 ` [Qemu-devel] [PATCH 5/7] migration: create now section to store global state Juan Quintela
2014-10-20 10:52   ` Dr. David Alan Gilbert
2014-10-20 11:11   ` Kevin Wolf
2014-10-15  7:55 ` [Qemu-devel] [PATCH 6/7] global_state: Make section optional Juan Quintela
2014-10-15  7:55 ` [Qemu-devel] [PATCH 7/7] vmstate: Create optional sections Juan Quintela
2014-10-15 14:45   ` Eric Blake
2014-10-15 14:57 ` [Qemu-devel] [RFC 0/7] Optional toplevel sections Eric Blake
2014-10-15 15:59   ` Juan Quintela
2014-10-15 16:37     ` Eric Blake
2014-10-17 13:41     ` Paolo Bonzini
2014-10-20 14:59       ` Dr. David Alan Gilbert
2014-10-20 11:29 ` Kevin Wolf [this message]

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=20141020112943.GG3585@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=laine@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /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).