Peter Crosthwaite writes:
> Hi Markus,
>
> I consolidated this discussion into a new RFC which proposes a few
> solutions the the bdrv_read() from init() problem.
>
> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg00237.html
>
> Are you able to comment on those ideas WRT your latest thou
On Thu, Jul 12, 2012 at 11:42 PM, Markus Armbruster wrote:
> Kevin Wolf writes:
>
>> Am 02.07.2012 11:42, schrieb Peter Crosthwaite:
>>> On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf wrote:
Am 02.07.2012 10:57, schrieb Peter Crosthwaite:
> No conditional on the qemu_coroutine_create. So it
Kevin Wolf writes:
> Am 02.07.2012 11:42, schrieb Peter Crosthwaite:
>> On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf wrote:
>>> Am 02.07.2012 10:57, schrieb Peter Crosthwaite:
No conditional on the qemu_coroutine_create. So it will always create
a new coroutine for its work which will so
On Mon, Jul 2, 2012 at 9:19 PM, Kevin Wolf wrote:
> Am 02.07.2012 13:12, schrieb Peter Crosthwaite:
>> On Mon, Jul 2, 2012 at 8:44 PM, Kevin Wolf wrote:
>>> Am 02.07.2012 12:18, schrieb Peter Maydell:
On 2 July 2012 11:01, Kevin Wolf wrote:
> Reading from block devices during device ini
Am 02.07.2012 13:12, schrieb Peter Crosthwaite:
> On Mon, Jul 2, 2012 at 8:44 PM, Kevin Wolf wrote:
>> Am 02.07.2012 12:18, schrieb Peter Maydell:
>>> On 2 July 2012 11:01, Kevin Wolf wrote:
Reading from block devices during device initialisation breaks
migration, so I'd like to see it
On Mon, Jul 2, 2012 at 8:44 PM, Kevin Wolf wrote:
> Am 02.07.2012 12:18, schrieb Peter Maydell:
>> On 2 July 2012 11:01, Kevin Wolf 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 im
Am 02.07.2012 12:57, schrieb Peter Crosthwaite:
> On Mon, Jul 2, 2012 at 8:52 PM, Kevin Wolf wrote:
>> Am 02.07.2012 12:18, schrieb Peter Crosthwaite:
>>> On Mon, Jul 2, 2012 at 8:01 PM, Kevin Wolf wrote:
Am 02.07.2012 11:42, schrieb Peter Crosthwaite:
> On Mon, Jul 2, 2012 at 7:04 PM, K
On Mon, Jul 2, 2012 at 8:59 PM, Peter Maydell wrote:
> On 2 July 2012 11:44, Kevin Wolf wrote:
>> Am 02.07.2012 12:18, schrieb Peter Maydell:
>>> Why complicate things by adding code for "if this is the first
>>> access then read in the file"?
>>
>> Because then it works. :-)
>>
>> Migration work
On 2 July 2012 11:44, Kevin Wolf wrote:
> Am 02.07.2012 12:18, schrieb Peter Maydell:
>> 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 mod
On Mon, Jul 2, 2012 at 8:52 PM, Kevin Wolf wrote:
> Am 02.07.2012 12:18, schrieb Peter Crosthwaite:
>> On Mon, Jul 2, 2012 at 8:01 PM, Kevin Wolf wrote:
>>> Am 02.07.2012 11:42, schrieb Peter Crosthwaite:
On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf wrote:
> Am 02.07.2012 10:57, schrieb P
Am 02.07.2012 12:18, schrieb Peter Crosthwaite:
> On Mon, Jul 2, 2012 at 8:01 PM, Kevin Wolf wrote:
>> Am 02.07.2012 11:42, schrieb Peter Crosthwaite:
>>> On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf wrote:
Am 02.07.2012 10:57, schrieb Peter Crosthwaite:
> No conditional on the qemu_corout
Am 02.07.2012 12:18, schrieb Peter Maydell:
> On 2 July 2012 11:01, Kevin Wolf 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
>>
On Mon, Jul 2, 2012 at 8:01 PM, Kevin Wolf wrote:
> Am 02.07.2012 11:42, schrieb Peter Crosthwaite:
>> On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf wrote:
>>> Am 02.07.2012 10:57, schrieb Peter Crosthwaite:
No conditional on the qemu_coroutine_create. So it will always create
a new corout
On 2 July 2012 11:01, Kevin Wolf 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
Am 02.07.2012 11:42, schrieb Peter Crosthwaite:
> On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf wrote:
>> Am 02.07.2012 10:57, schrieb Peter Crosthwaite:
>>> No conditional on the qemu_coroutine_create. So it will always create
>>> a new coroutine for its work which will solve my problem. All I need
On Mon, Jul 2, 2012 at 7:04 PM, Kevin Wolf wrote:
> Am 02.07.2012 10:57, schrieb Peter Crosthwaite:
>> On Mon, Jul 2, 2012 at 6:50 PM, Stefan Hajnoczi wrote:
>>> On Fri, Jun 29, 2012 at 12:51 PM, Peter Crosthwaite
>>> wrote:
BTW Yielding is one thing, but the elephant in the room here is
>>
Am 02.07.2012 10:57, schrieb Peter Crosthwaite:
> On Mon, Jul 2, 2012 at 6:50 PM, Stefan Hajnoczi wrote:
>> On Fri, Jun 29, 2012 at 12:51 PM, Peter Crosthwaite
>> wrote:
>>> BTW Yielding is one thing, but the elephant in the room here is
>>> resumption of the coroutine. When AIO yields my corouti
On Mon, Jul 2, 2012 at 6:50 PM, Stefan Hajnoczi wrote:
> On Fri, Jun 29, 2012 at 12:51 PM, Peter Crosthwaite
> wrote:
>> BTW Yielding is one thing, but the elephant in the room here is
>> resumption of the coroutine. When AIO yields my coroutine I i need to
>> talk to AIO to get it unyielded (Ste
On Fri, Jun 29, 2012 at 12:51 PM, Peter Crosthwaite
wrote:
> BTW Yielding is one thing, but the elephant in the room here is
> resumption of the coroutine. When AIO yields my coroutine I i need to
> talk to AIO to get it unyielded (Stefans propsoed edit to my code).
> What happens when tommorow so
Can anoyne explain to me the consequences of my patch btw? I am
struggling to see how co-routines actually call into the block layer
API (without already being there) such that these fast paths are even
activated?
>>>
>>> No, the assumption is a completely different one and it has nothing to
>>> d
Peter Crosthwaite writes:
> On Jun 29, 2012 6:24 PM, "Kevin Wolf" wrote:
>>
>> Am 29.06.2012 02:50, schrieb Peter Crosthwaite:
>> >>
>> >> The problem I see is:
>> >>
>> >> FDTMachineInfo *fdt_generic_create_machine()
>> >> {
>> >>...
>> >>while (qemu_co_queue_enter_next(fdti->cq));
>> >
On Jun 29, 2012 6:24 PM, "Kevin Wolf" wrote:
>
> Am 29.06.2012 02:50, schrieb Peter Crosthwaite:
> >>
> >> The problem I see is:
> >>
> >> FDTMachineInfo *fdt_generic_create_machine()
> >> {
> >>...
> >>while (qemu_co_queue_enter_next(fdti->cq));
> >> }
> >>
> >> The problem you have is no
Am 29.06.2012 02:50, schrieb Peter Crosthwaite:
>>
>> The problem I see is:
>>
>> FDTMachineInfo *fdt_generic_create_machine()
>> {
>>...
>>while (qemu_co_queue_enter_next(fdti->cq));
>> }
>>
>> The problem you have is not that the block layer is yielding. The
>> problem is that you need t
Hi Stefan.
On Thu, Jun 28, 2012 at 11:03 PM, Stefan Hajnoczi wrote:
> On Thu, Jun 28, 2012 at 4:17 AM, Peter Crosthwaite
> wrote:
not at a valid yield point. But whats really wrong here is the block
layer will be making assumption on re-entry of the coroutine, so I
cant re-enter i
On Thu, Jun 28, 2012 at 4:17 AM, Peter Crosthwaite
wrote:
>>> not at a valid yield point. But whats really wrong here is the block
>>> layer will be making assumption on re-entry of the coroutine, so I
>>> cant re-enter it witout wildly changing the behaviour of the block
>>> layer. If you adopt t
>> not at a valid yield point. But whats really wrong here is the block
>> layer will be making assumption on re-entry of the coroutine, so I
>> cant re-enter it witout wildly changing the behaviour of the block
>> layer. If you adopt this "mark it as coroutine" poilcy, you end up
>> with a system
On Wed, Jun 27, 2012 at 10:25 AM, Peter Crosthwaite
wrote:
> On Wed, Jun 27, 2012 at 6:33 PM, Markus Armbruster wrote:
>> Stefan Hajnoczi writes:
>>
>>> On Wed, Jun 27, 2012 at 8:59 AM, Peter Maydell
>>> wrote:
On 27 June 2012 08:48, Stefan Hajnoczi wrote:
> I'd like to see your code
On Wed, Jun 27, 2012 at 6:33 PM, Markus Armbruster wrote:
> Stefan Hajnoczi writes:
>
>> On Wed, Jun 27, 2012 at 8:59 AM, Peter Maydell
>> wrote:
>>> On 27 June 2012 08:48, Stefan Hajnoczi wrote:
I'd like to see your code though because I still don't understand why
it relies on the e
On 27 June 2012 10:10, Andreas Färber wrote:
> Maybe I'm misunderstanding the discussion, but there's three coroutine
> implementations, including one based on GThread. So in that case any
> coroutine can be preempted anywhere and there are no such guarantees as
> discussed here, are there?
No, b
Am 22.06.2012 12:59, schrieb Peter Crosthwaite:
> On Fri, Jun 22, 2012 at 6:53 PM, Kevin Wolf wrote:
>> Am 22.06.2012 10:20, schrieb Peter Crosthwaite:
>>> [...] I thought that was the point of coroutines vs
>>> threads? coroutines you control yield behaviour explicitly whearas
>>> thread you cant
Stefan Hajnoczi writes:
> On Wed, Jun 27, 2012 at 8:59 AM, Peter Maydell
> wrote:
>> On 27 June 2012 08:48, Stefan Hajnoczi wrote:
>>> I'd like to see your code though because I still don't understand why
>>> it relies on the exact yield behavior. Have you pushed it to a public
>>> git repo?
On Wed, Jun 27, 2012 at 8:59 AM, Peter Maydell wrote:
> On 27 June 2012 08:48, Stefan Hajnoczi wrote:
>> I'd like to see your code though because I still don't understand why
>> it relies on the exact yield behavior. Have you pushed it to a public
>> git repo?
>
> I haven't seen Peter's code eit
On 27 June 2012 08:48, Stefan Hajnoczi wrote:
> I'd like to see your code though because I still don't understand why
> it relies on the exact yield behavior. Have you pushed it to a public
> git repo?
I haven't seen Peter's code either, but his complaint makes sense
to me -- the whole point of
On Wed, Jun 27, 2012 at 4:05 AM, Peter Crosthwaite
wrote:
> I still think this thread points out a major flaw in block+coroutines,
> regardless of the fact im using it from a machine model. This bug is
> going to happen in any coroutine code that touches the block layer
> (E.G. what happens if the
Ping!
Any Further thoughts Kevin?
This thread flew off on a tangent over whether or not coroutines
should be depracated. Seems to be the answer there was no on that
front - coroutines are here to stay.
I still think this thread points out a major flaw in block+coroutines,
regardless of the fact
Peter Maydell writes:
> On 22 June 2012 13:04, Markus Armbruster wrote:
>> Peter Maydell writes:
>>
>>> On 22 June 2012 09:48, Markus Armbruster wrote:
In my opinion, coroutines have been useful for us so far. Whether they
remain useful, or serve us just as a stepping stone towards
On 22 June 2012 13:04, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On 22 June 2012 09:48, Markus Armbruster wrote:
>>> In my opinion, coroutines have been useful for us so far. Whether they
>>> remain useful, or serve us just as a stepping stone towards general
>>> threads remains to
Peter Maydell writes:
> On 22 June 2012 09:48, Markus Armbruster wrote:
>> In my opinion, coroutines have been useful for us so far. Whether they
>> remain useful, or serve us just as a stepping stone towards general
>> threads remains to be seen.
>
>>From my point of view I've seen a whole pil
On Fri, Jun 22, 2012 at 6:53 PM, Kevin Wolf wrote:
> Am 22.06.2012 10:20, schrieb Peter Crosthwaite:
>> On Fri, Jun 22, 2012 at 5:49 PM, Kevin Wolf wrote:
>>> Am 22.06.2012 08:44, schrieb Peter A. G. Crosthwaite:
The block layer assumes that it is the only user of coroutines -
The qemu_
On 22 June 2012 09:48, Markus Armbruster wrote:
> In my opinion, coroutines have been useful for us so far. Whether they
> remain useful, or serve us just as a stepping stone towards general
> threads remains to be seen.
>From my point of view I've seen a whole pile of problems and not
really an
Am 22.06.2012 10:20, schrieb Peter Crosthwaite:
> On Fri, Jun 22, 2012 at 5:49 PM, Kevin Wolf wrote:
>> Am 22.06.2012 08:44, schrieb Peter A. G. Crosthwaite:
>>> The block layer assumes that it is the only user of coroutines -
>>> The qemu_in_coroutine() is used to determine if a function is in on
Peter Maydell writes:
> On 22 June 2012 09:00, Peter Crosthwaite
> wrote:
>> On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka wrote:
>>> Not sure if I understood the intention yet: Is this supposed to fix an
>>> issue with the current usage of coroutines or to extend their usage
>>> beyond that? In
Am 22.06.2012 10:16, schrieb Peter Maydell:
> On 22 June 2012 09:00, Peter Crosthwaite
> wrote:
>> On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka wrote:
>>> Not sure if I understood the intention yet: Is this supposed to fix an
>>> issue with the current usage of coroutines or to extend their usage
On Fri, Jun 22, 2012 at 9:31 AM, Peter Maydell wrote:
> On 22 June 2012 09:20, Peter Crosthwaite
> wrote:
>> Its a machine model that instantiated some block devices concurrently.
>> Theres some chicken-and-egg issues with the instantiation such that
>> they have the happen concurrently. One devi
On Fri, Jun 22, 2012 at 9:16 AM, Peter Maydell wrote:
> On 22 June 2012 09:00, Peter Crosthwaite
> wrote:
>> On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka wrote:
>>> Not sure if I understood the intention yet: Is this supposed to fix an
>>> issue with the current usage of coroutines or to extend t
On 22 June 2012 09:20, Peter Crosthwaite
wrote:
> Its a machine model that instantiated some block devices concurrently.
> Theres some chicken-and-egg issues with the instantiation such that
> they have the happen concurrently. One device instantiates a block
> device (pflash_cfi_01) from coroutin
On Fri, Jun 22, 2012 at 6:16 PM, Peter Maydell wrote:
> On 22 June 2012 09:00, Peter Crosthwaite
> wrote:
>> On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka wrote:
>>> Not sure if I understood the intention yet: Is this supposed to fix an
>>> issue with the current usage of coroutines or to extend t
On Fri, Jun 22, 2012 at 5:49 PM, Kevin Wolf wrote:
> Am 22.06.2012 08:44, schrieb Peter A. G. Crosthwaite:
>> The block layer assumes that it is the only user of coroutines -
>> The qemu_in_coroutine() is used to determine if a function is in one of the
>> block layers coroutines, which is flawed.
On 22 June 2012 09:00, Peter Crosthwaite
wrote:
> On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka wrote:
>> Not sure if I understood the intention yet: Is this supposed to fix an
>> issue with the current usage of coroutines or to extend their usage
>> beyond that? In the latter case, please don't do
Am 22.06.2012 10:00, schrieb Peter Crosthwaite:
> On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka wrote:
>> On 2012-06-22 08:44, Peter A. G. Crosthwaite wrote:
>>> The block layer assumes that it is the only user of coroutines -
>>> The qemu_in_coroutine() is used to determine if a function is in one
On Fri, Jun 22, 2012 at 5:50 PM, Jan Kiszka wrote:
> On 2012-06-22 08:44, Peter A. G. Crosthwaite wrote:
>> The block layer assumes that it is the only user of coroutines -
>> The qemu_in_coroutine() is used to determine if a function is in one of the
>> block layers coroutines, which is flawed. I
On 2012-06-22 08:44, Peter A. G. Crosthwaite wrote:
> The block layer assumes that it is the only user of coroutines -
> The qemu_in_coroutine() is used to determine if a function is in one of the
> block layers coroutines, which is flawed. I.E. If a client (e.g. a device or
> a machine model) of t
Am 22.06.2012 08:44, schrieb Peter A. G. Crosthwaite:
> The block layer assumes that it is the only user of coroutines -
> The qemu_in_coroutine() is used to determine if a function is in one of the
> block layers coroutines, which is flawed. I.E. If a client (e.g. a device or
> a machine model) of
The block layer assumes that it is the only user of coroutines -
The qemu_in_coroutine() is used to determine if a function is in one of the
block layers coroutines, which is flawed. I.E. If a client (e.g. a device or
a machine model) of the block layer uses couroutine itself, the block layer
will
54 matches
Mail list logo
