Re: Stubdom breakage in 4.5

[Don Slutz <dslutz@verizon.com>]

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@lists.xen.org; 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@citrix.com]
>>>> Sent: 03 February 2015 12:22
>>>> To: xen-devel@lists.xen.org
>>>> 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@terremark.com>; 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@lists.xen.org
> http://lists.xen.org/xen-devel
>