[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Stubdom breakage in 4.5
On 02/03/15 09:00, Paul Durrant wrote: >> -----Original Message----- >> From: Ian Campbell >> Sent: 03 February 2015 13:48 >> To: Paul Durrant >> Cc: Wei Liu; xen-devel@xxxxxxxxxxxxx; Ian Jackson; Jan Beulich; Andrew >> Cooper; Stefano Stabellini >> Subject: Re: Stubdom breakage in 4.5 >> >> On Tue, 2015-02-03 at 13:42 +0000, Paul Durrant wrote: >>>> -----Original Message----- >>>> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx] >>>> Sent: 03 February 2015 12:22 >>>> To: xen-devel@xxxxxxxxxxxxx >>>> Cc: Wei Liu; Ian Campbell; Ian Jackson; Paul Durrant; Jan Beulich; Andrew >>>> Cooper; Stefano Stabellini >>>> Subject: Stubdom breakage in 4.5 >>>> >>>> Hi all >>>> >>>> I recently found out that stubdom in 4.5 is broken. >> Either way, this regression certainly needs fixing in 4.5 as well as >> unstable/4.6. It's my understanding that the stuff Don is doing is (at >> least partially) addressing the latter? >> > > No, I don't think the stuff Don is doing will help this. He has need to steer > his emulation requests, which are new and distinct. The case here is that you > need an emulator for existent types of IOREQ to be present before the guest > gets going and the toolstack is not ensuring this, so yes, forcibly creating > the default emulator during domain build would solve that problem. However it > does introduce another problem... > Upstream QEMU now no longer hooks into Xen as the default emulator and > therefore will not get emulation requests for the TPM probe done by > hvmloader; those are now completed by Xen but would end up wedging the VM if > Xen thought that a default emulator would eventually turn up. So, forcible > creation of the default emulator would still need to be something that could > be turned off if the latest upstream QEMU were in use. > Most of what I have posted does not apply. The only possible one that comes to mind is about using QEMU master (of the newer 4.6 QEMU) with 4.5 which I am assuming is not the case here (for reference it is about creating a default_ioreq_server to the QEMU that did call hvm_ioreq_server_enable() 1st, and then a 2nd time as the default one. (Message-ID: <54CAEF19.1030205@xxxxxxxxxxxxx>; Subject: Re: [Qemu-devel] [PATCH v5 2/2] Xen: Use the ioreq-server API when available)). -Don Slutz >> Paul, can you take care of fixing, or ensuring someone else is fixing, >> the issue, please. >> > > I'm happy to fix once the best course of action is agreed. > > Paul > > >> Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |