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
next prev parent 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).