qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	stefanha@linux.vnet.ibm.com, Stefan Hajnoczi <stefanha@gmail.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, edgar.iglesias@gmail.com,
	john.williams@petalogix.com
Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption
Date: Mon, 02 Jul 2012 13:19:43 +0200	[thread overview]
Message-ID: <4FF183CF.9010003@redhat.com> (raw)
In-Reply-To: <CAEgOgz7U-p+Myf5neD9TdoWjxaEwu0KFQUY0qxQZHc4=X-i_1Q@mail.gmail.com>

Am 02.07.2012 13:12, schrieb Peter Crosthwaite:
> On Mon, Jul 2, 2012 at 8:44 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 02.07.2012 12:18, schrieb Peter Maydell:
>>> On 2 July 2012 11:01, Kevin Wolf <kwolf@redhat.com> wrote:
>>>> Reading from block devices during device initialisation breaks
>>>> migration, so I'd like to see it go away wherever possible. Reading in
>>>> the whole image file doesn't sound like something for which a good
>>>> excuse exists, you can do that as well during the first access.
>>>
>>> It's much nicer to be able to produce an error message ("file
>>> doesn't exist", "file is too short for this flash device") at
>>> device startup rather than miles later on at first access,
>>
>> "file doesn't exist" is an error that occurs for the backend (-drive
>> if=none), not for the -device, so you shouldn't have to deal with that
>> at all.
>>
>>> and pulling in a 64K file at startup is a simple implementation.
>>> Why complicate things by adding code for "if this is the first
>>> access then read in the file"?
>>
>> Because then it works. :-)
>>
>> Migration works more or less like this:
>>
>> 1. Destination creates device model based on command line
>> 2. RAM is copied live, source keeps running
>> 3. Source stops, device state is transferred
>> 4. Destination starts running the VM
>>
>> Reading from a block device is meaningful the earliest in step 3,
>> because at earlier points the guest still runs on the source and can
>> overwrite the data on the block device. If you're reading in the whole
>> image, you're doing it in step 1, so your data will be outdated by the
>> time the migration completes.
>>
> 
> I feel like theres a "two birds with one stone" solution here, by
> making bdrv_aio_read just yield until step 3? Just an if (..)
> somewhere in the bdrv framework that says "while not ready for
> migration qemu_coroutine_yield()". You implement the postponed
> bdrv_read that you want, but you also get rid of the bdrv_read()s that
> everyone hates without having the rewrite all the small flashes with
> if-first-read-load-all logic.

Or we could just have a second "late init" callback into the devices
where such requests could be issued. That would feel a bit cleaner.

Kevin

  reply	other threads:[~2012-07-02 11:20 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-22  6:44 [Qemu-devel] [RFC] block: Removed coroutine ownership assumption Peter A. G. Crosthwaite
2012-06-22  7:49 ` Kevin Wolf
2012-06-22  8:20   ` Peter Crosthwaite
2012-06-22  8:31     ` Peter Maydell
2012-06-22  8:34       ` Stefan Hajnoczi
2012-06-22  8:53     ` Kevin Wolf
2012-06-22 10:59       ` Peter Crosthwaite
     [not found]         ` <CAEgOgz4+5FsFUZT796chTADOXcRps0+74T4whfmdEsh_dO96VA@mail.gmail.com>
     [not found]           ` <CAJSP0QWVJTb9jPZC_mdWpd4OwLz4VOuxGBZ_=2M4HNeexEC96Q@mail.gmail.com>
     [not found]             ` <CAFEAcA_cX_jxZMSjjT=yBA1Hmf2VpWbGyDBZ8z9mqq5rVNsWWw@mail.gmail.com>
     [not found]               ` <CAJSP0QV=BsRhdD_tVE9Cav-bhGiF-R3+Ab2aTtun6nSoPh0EmQ@mail.gmail.com>
     [not found]                 ` <m3vcidw3v3.fsf@blackfin.pond.sub.org>
     [not found]                   ` <CAEgOgz6Mai7PvBkHwN0EjhFsAFMU8W=V1B1X0ZLN3c1YHRaWKA@mail.gmail.com>
     [not found]                     ` <CAJSP0QWJcuEOmxhoAceqU2WYQkGT+fsizf-kdx_irq97j3pw4Q@mail.gmail.com>
     [not found]                       ` <CAEgOgz51jauHzvEk0Pk+oNQ0qPekjKatvNivv4vxQsQR_6nOVQ@mail.gmail.com>
     [not found]                         ` <CAJSP0QXnaw2HV7M+U=0S-ApGGnrGtt1w0P5w5gpmv7h-7bMs9g@mail.gmail.com>
     [not found]                           ` <CAEgOgz65h2baE0ufvSgfow-B5fGVwJKgNwsf3C2r65HNGdiQxg@mail.gmail.com>
     [not found]                             ` <4FED6638.90703@redhat.com>
     [not found]                               ` <CAEgOgz6sUREnwNuiSM=344ZTNq_4xMJDFU29Sn+6dTeVww4rhA@mail.gmail.com>
     [not found]                                 ` <m3y5n61hl5.fsf@blackfin.pond.sub.org>
     [not found]                                   ` <CAEgOgz7oPPsMexuzsYwc2LOGGOC4EM9NvHjXAp0TT2T8kOyirQ@mail.gmail.com>
2012-07-02  8:50                                     ` Stefan Hajnoczi
2012-07-02  8:57                                       ` Peter Crosthwaite
2012-07-02  9:04                                         ` Kevin Wolf
2012-07-02  9:42                                           ` Peter Crosthwaite
2012-07-02 10:01                                             ` Kevin Wolf
2012-07-02 10:18                                               ` Peter Maydell
2012-07-02 10:44                                                 ` Kevin Wolf
2012-07-02 10:59                                                   ` Peter Maydell
2012-07-02 11:03                                                     ` Peter Crosthwaite
2012-07-02 11:12                                                   ` Peter Crosthwaite
2012-07-02 11:19                                                     ` Kevin Wolf [this message]
2012-07-02 11:25                                                       ` Peter Crosthwaite
2012-07-02 10:18                                               ` Peter Crosthwaite
2012-07-02 10:52                                                 ` Kevin Wolf
2012-07-02 10:57                                                   ` Peter Crosthwaite
2012-07-02 11:04                                                     ` Kevin Wolf
2012-07-12 13:42                                               ` Markus Armbruster
2012-07-13  1:21                                                 ` Peter Crosthwaite
2012-07-13  8:33                                                   ` Markus Armbruster
2012-06-22  7:50 ` Jan Kiszka
2012-06-22  8:00   ` Peter Crosthwaite
2012-06-22  8:06     ` Kevin Wolf
2012-06-22  8:16     ` Peter Maydell
2012-06-22  8:23       ` Peter Crosthwaite
2012-06-22  8:33       ` Stefan Hajnoczi
2012-06-22  8:45       ` Kevin Wolf
2012-06-22  8:48       ` Markus Armbruster
2012-06-22  9:06         ` Peter Maydell
2012-06-22 12:04           ` Markus Armbruster
2012-06-22 12:30             ` Peter Maydell
2012-06-22 13:36               ` Markus Armbruster

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=4FF183CF.9010003@redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=john.williams@petalogix.com \
    --cc=peter.crosthwaite@petalogix.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@linux.vnet.ibm.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).