From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Stubdom breakage in 4.5 Date: Wed, 4 Feb 2015 12:30:01 +0000 Message-ID: <1423053001.17711.41.camel@citrix.com> References: <20150203122226.GB20260@zion.uk.xensource.com> <9AAE0902D5BC7E449B7C8E4E778ABCD0257E12B5@AMSPEX01CL01.citrite.net> <1422971272.9323.92.camel@citrix.com> <9AAE0902D5BC7E449B7C8E4E778ABCD0257E13AD@AMSPEX01CL01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0257E13AD@AMSPEX01CL01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paul Durrant Cc: Wei Liu , Andrew Cooper , "xen-devel@lists.xen.org" , Stefano Stabellini , Jan Beulich , Ian Jackson List-Id: xen-devel@lists.xenproject.org On Tue, 2015-02-03 at 14:11 +0000, Paul Durrant wrote: > How about this as a slightly hacky solution that I think may work in both cases? > > If Xen finds no emulator at all for an HVM guest then it waits around > for at least one to show up before processing an emulation request. > Until one does it stalls the vcpu in question indefinitely, but on the > first emulator attach (i.e. ioreq server creations) then the IO will > always be processed, even if it doesn't match the ioreq server. It sounds plausible to me and seems like it would probably be backportable. Longer term I think we still need to fix the domain creation interlock for launching multiple qemu's, ioreq servers and any other type of service thing we might launch (whether in a stub dom or not), at which point we may be able to remove the above workaround too. Ian.