Re: [Xen-devel] [GIT PULL] remove xend for 4.5 (Was: Re: [PATCH] MAINTAINERS: Exclude xend from toolstack maintainers entry)

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Monday, March 31, 2014, 4:08:10 PM, you wrote:

> On 03/31/2014 03:05 PM, Fabio Fantoni wrote:
>> Il 31/03/2014 15:17, George Dunlap ha scritto:
>>> On 03/31/2014 01:16 PM, Matt Wilson wrote:
>>>> On Mon, Mar 31, 2014 at 01:03:25PM +0100, George Dunlap wrote:
>>>>> On 03/31/2014 12:56 PM, Matt Wilson wrote:
>>>>>> On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote:
>>>>>>> On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote:
>>>>>> [...]
>>>>>>
>>>>>>>> I don't really like adding more of 'xend has this' to the list,
>>>>>>> that's ok.
>>>>>>>
>>>>>>>> but
>>>>>>>> Jan discovered that 'xend' was using the group assigment 
>>>>>>>> hypercall for
>>>>>>>> PCI devices while 'xl' is not doing that.
>>>>>>>> That hypercall has certain benefits - you can use it to figure 
>>>>>>>> out if
>>>>>>>> all of the PCI devices underneath a bridge are assigned to one
>>>>>>>> guest and not shared amongts the guests.
>>>>>>> I think this is at the wishlist rather than blocker end of the 
>>>>>>> spectrum,
>>>>>>> and probably falls under the general category of "xl pci 
>>>>>>> passthrough has
>>>>>>> sharp edges"? Does that sound right?
>>>>>> Probably. There are other areas that are mightily sharp as well. They
>>>>>> might not be blockers for the project to remove Xend code from the
>>>>>> tree, but they'll be blockers for adoption of newer releases that
>>>>>> don't include Xend.
>>>>>>
>>>>>> Another for the list is AER handling. That's only implemented in Xend
>>>>>> now [1].
>>>>> Well, given that AER was not mentioned 6 months ago when this came
>>>>> up, it seems that keeping xend in tree is a blocker for people
>>>>> actually asking for things to be added to xl.
>>>> Actually, we discussed it on the phone [1]. Unfortunately I didn't
>>>> complete my assigned action item to post on the list.
>>>
>>> Ah, right. :-)
>>>
>>> In any case, the relevant question isn't so much "Is this a blocker 
>>> for xend removal", so much as "Is xl support for this a blocker for 
>>> the 4.5 release?"
>>
>> There is another thing to do in libxl to solve the problem of network 
>> not working after restore.
>> Actually the only workaround is to assign fixed mac address in xl cfg.
>> I reported this during 4.2 development but it was too late to "fix" it 
>> if I remember good.
>>
>> Thanks for any reply.

> Yes, this is on our list, and I think it should be a blocker for 4.5.

> For future reference, please don't change the subject -- this thread is 
> about xend / xl functionality, not general 4.5 planning. (Hopefully 
> those e-mails should start soon.)

Since some xend -> xl items could also be qemu related, what is the general 
opinion
about qemu-trad -> qemu-(xen|upstream) for these items ?

Should they also be implemented for qemu traditional or only for 
qemu-(xen|upstream) ?

--
Sander

>   -George




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel