[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.