From: Eric Blake <eblake@redhat.com>
To: Andrew Baumann <Andrew.Baumann@microsoft.com>, qemu-devel@nongnu.org
Cc: Andrey Shedel <ashedel@microsoft.com>,
Stefan Weil <sw@weilnetz.de>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] win32: replace custom mutex and condition variable with native primitives
Date: Fri, 24 Mar 2017 17:30:27 -0500 [thread overview]
Message-ID: <62183d63-73fb-0fa4-09e9-4519de6a003a@redhat.com> (raw)
In-Reply-To: <20170324220141.10104-1-Andrew.Baumann@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]
On 03/24/2017 05:01 PM, Andrew Baumann wrote:
> From: Andrey Shedel <ashedel@microsoft.com>
>
> The multithreaded TCG implementation exposed deadlocks in the win32
> condition variables: as implemented, qemu_cond_broadcast waited on
> receivers, whereas the pthreads API it was intended to emulate does
> not. This was causing a deadlock because broadcast was called while
> holding the IO lock, as well as all possible waiters blocked on the
> same lock.
>
> This patch replaces all the custom synchronisation code for mutexes
> and condition variables with native Windows primitives (SRWlocks and
> condition variables) with the same semantics as their POSIX
> equivalents. To enable that, it requires a Windows Vista or newer host
> OS.
>
> [AB: edited commit message]
> Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
> ---
> The major implication of this patch is that it drops support for
> pre-Vista versions of Windows. However, those OSes are past their end
> of life, and other OSS projects have dropped support. e.g.; the last
> Cygwin release supporting XP was in Jun 2016. It doesn't seem like a
> good tradeoff to invest effort in fixing broken code needed to support
> them, so hopefully this isn't too controversial.
I'll leave the technical review to others, but from the pragmatic view,
I'm in favor of this change. While we still strive to let qemu run
past-their-prime OSs (like pre-Vista) as guests, it is a different story
for the host, and I'm totally fine with stating that our mingw build
requires a host OS that is not past end-of-life.
Furthermore, our recent thread on which OSs should still be supported
for builds should be evidence that we are willing to drop old code for
hosts that cannot be set up as a build-bot; and I see no reason that
anyone running an out-of-date Windows XP box would want to expose it to
the internet to be a build-bot given that it has known security flaws
that will not be patched.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2017-03-24 22:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 22:01 [Qemu-devel] [PATCH] win32: replace custom mutex and condition variable with native primitives Andrew Baumann
2017-03-24 22:25 ` Paolo Bonzini
2017-03-24 22:28 ` Paolo Bonzini
2017-03-24 23:14 ` Andrew Baumann
2017-03-25 10:14 ` Paolo Bonzini
2017-03-25 17:43 ` Andrey Shedel
2017-03-24 22:30 ` Eric Blake [this message]
2017-04-03 14:20 ` Cornelia Huck
2017-04-03 18:12 ` Andrew Baumann
2017-04-04 6:35 ` Cornelia Huck
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=62183d63-73fb-0fa4-09e9-4519de6a003a@redhat.com \
--to=eblake@redhat.com \
--cc=Andrew.Baumann@microsoft.com \
--cc=ashedel@microsoft.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
/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).