All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.