On Mon, Feb 07, 2011 at 03:02:03PM -0600, Anthony Liguori wrote: > On 02/07/2011 11:10 AM, Jan Kiszka wrote: >> On 2011-02-07 17:23, Paolo Bonzini wrote: >> >>> On 02/07/2011 05:03 PM, Marcelo Tosatti wrote: >>> >>>> Is there any other issue that prevents turning CONFIG_IOTHREAD on by >>>> default? >>>> >>> I think Windows support. >>> >>> Signal support is actually easy because we can "hack" the IPI as >>> "suspend the VCPU thread+do work in the iothread context+resume the VCPU >>> thread" (the IPI handler doesn't longjmp). >>> >>> Threading primitives support is tricky but not hard (there is lots of >>> code around, especially if you can make assumptions such as "always hold >>> the mutex while signaling a cond. variable"). >>> >> !CONFIG_IOTHREAD code is doomed to bitrot once we switch to default >> iothread mode. So if Windows support is not converted to a threading >> model with moderate differences to POSIX, it will likely bitrot a well. >> Therefore, conversion should be started rather sooner than later (by >> someone interested in that platform). >> > > As far as I'm concerned, Windows support is already deprecated as noone > has stepped up to enhance it or support for a number of years now. We > shouldn't remove existing code that supports it or refuse to take > reasonable patches but if enabling IO thread by default breaks it, so be > it.
As far as I see, Blue Swirl and Stefan Weil are regularly committing fixes for win32. Stefan Weil is also providing win32 binaries on his website [1]. I wouldn't call that deprecated. [1] http://qemu.weilnetz.de/ -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
