Re: [Qemu-devel] [PULL 42/57] Page request: Consume pages off the post-copy queue

[Peter Maydell]

On 12 November 2015 at 12:04, Dr. David Alan Gilbert
<address@hidden> wrote:
> * Peter Maydell (address@hidden) wrote:
>> On 10 November 2015 at 14:25, Juan Quintela <address@hidden> wrote:
>> > From: "Dr. David Alan Gilbert" <address@hidden>
>> >
>> > When transmitting RAM pages, consume pages that have been queued by
>> > MIG_RPCOMM_REQPAGE commands and send them ahead of normal page scanning.
>> >
>> > Note:
>> >   a) After a queued page the linear walk carries on from after the
>> > unqueued page; there is a reasonable chance that the destination
>> > was about to ask for other closeby pages anyway.
>> >
>> >   b) We have to be careful of any assumptions that the page walking
>> > code makes, in particular it does some short cuts on its first linear
>> > walk that break as soon as we do a queued page.
>> >
>> >   c) We have to be careful to not break up host-page size chunks, since
>> > this makes it harder to place the pages on the destination.
>> >
>> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
>> > Reviewed-by: Juan Quintela <address@hidden>
>> > Signed-off-by: Juan Quintela <address@hidden>
>>
>> I've just discovered that this is causing 'make check' failures on
>> my OSX host (unfortunately something in my setup is causing
>> 'make check' failures to not always cause a build failure, so I
>> didn't notice earlier):
>
> It's only failing on OSX? Every time or only sometimes?

Only OSX, and always. I think OSX is pickier about mutexes really
needing to be initialized before use.

> If you can find a way to get a backtrace off that qemu_mutex_lock case
> that would be great; I'd assume the later errors are the fall out from that.

I'll have a look after lunch, but it's usually painful to get a
backtrace out of this kind of qtest, because it's clearly starting
a whole pile of QEMUs and there's no way I know of to say "only
run a few of these tests, not the whole huge pile".

thanks
-- PMM