Re: [Xen-devel] Xen 4.6 Development Update

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 16/02/15 13:24, Julien Grall wrote:
> (Strimming the cc list)

Sorry I forgot to add back xen-devel.

> On 16/02/15 12:38, wei.liu2@xxxxxxxxxx wrote:
>> Hi all
> 
> Hi Wei,
> 
>> We are now one month into 4.6 development window. This is an email to keep
>> track of all the patch series I gathered. It is by no means complete and / or
>> acurate. Feel free to reply this email with new projects or correct my
>> misunderstanding.
>>
>> = Timeline =
>>
>> We are planning on a 9-month release cycle, but we could also release a bit
>> earlier if everything goes well (no blocker, no critical bug).
>>
>> * Development start: 6 Jan 2015
>> * Feature Freeze: 10 Jul 2015
>> * RCs: TBD
>> * Release Date: 9 Oct 2015 (could release earlier)
>>
>> The RCs and release will of course depend on stability and bugs, and
>> will therefore be fairly unpredictable.
>>
>> Bug-fixes, if Acked-by by maintainer, can go anytime before the First
>> RC. Later on we will need to figure out the risk of regression/reward
>> to eliminate the possiblity of a bug introducing another bug.
>>
>> = Prognosis =
>>
>> The states are: none -> fair -> ok -> good -> done
>>
>> none - nothing yet
>> fair - still working on it, patches are prototypes or RFC
>> ok   - patches posted, acting on review
>> good - some last minute pieces
>> done - all done, might have bugs
>>
>> = Bug Fixes =
>>
>> Bug fixes can be checked in without a freeze exception throughout the
>> freeze, unless the maintainer thinks they are particularly high
>> risk.  In later RC's, we may even begin rejecting bug fixes if the
>> broken functionality is small and the risk to other functionality is
>> high.
>>
>> Document changes can go in anytime if the maintainer is OK with it.
>>
>> These are guidelines and principles to give you an idea where we're
>> coming from; if you think there's a good reason why making an
>> exception for you will help us achieve goals 1-3 above better than not
>> doing so, feel free to make your case.
>>
>> == Linux == 
>>
>> *  Block driver multiqueue support (fair)
>>    RFC posted
>>   -  Bob Liu
>>
>> *  Block driver multi-page ring support (fair)
>>   -  Bob Liu
>>
>> *  Preemptable privcmd hypercalls (good)
>>    v5 posted
>>   -  David Vrabel
>>
>> *  Linux ARM - Device assigment usage in Linux code (arch/arm) non-PCI (none)
>>    Depends on Xen pieces which are on the Xen 4.6 list.
>>   -  Julien Grall
> 
> I think we could defer this for after Xen 4.6. As we don't know yet the
> use cases, we decided to have a basic passthrough with doesn't require
> Linux modification.
> 
>> *  Linux ARM - Device assigment (PCI) (none)
>>    Depends on Xen pieces which are on the Xen 4.6 list.
>>   -  Manish Jaggi
>>
>> *  pvUSB in Linux (fronted and backend) (Fair)
>>   -  Juergen Gross
>>
>> *  VPMU - 'perf' support in Linux (ok)
>>    Depends on Xen patches
>>    Acked by David Vrabel
>>   -  Boris Ostrovsky
>>
>> *  vNUMA in Linux (ok)
>>    v6 posted
>>    git://gitorious.org/vnuma/linux_vnuma.git
>>   -  Elena Ufimtseva
>>
>> *  vsyscall in Linux (fair)
>>   -  Konrad Rzeszutek Wilk
>>
>> *  COLO Agent in Linux (fair)
>>   -  Gui Jianfeng
>>   -  Yang Hongyang
>>   -  Dong, Eddie
> 
> Another item to add in this section:
> 
> * ARM64 - support 64K guest (none)
>    No Xen side required for now
>   - Julien Grall
> 
> [..]
> 
>> == Hypervisor == 
> 
> It's a bit difficult for differentiate common/x86/arm features in this
> section. It would be nice if you either split this section in 3 or put
> together the features touching the same part of code.
> 
>> *  gnttab: improve scalability (good)
>>    v5 posted
>>   -  Christoph Egger
>>
>> *  arm: introduce basic Renesas R-Car Gen2 platform support (good)
>>    v5 posted
>>   -  Oleksandr Tyshchenko
> 
> It has been merged.
> 
> [..]
> 
>> *  ARM VM save/restore/live migration (none)
>>    Need to rebased against migrationv2 - no code posted.
>>   -  Junghyun Yoo
> 
> We didn't hear anything from Samsung since a while. I suspect someone
> will have to take this item.
> 
>> *  ARM GICv2m support (none)
>>   -  Linaro (unknown)
> 
> It won't be done by Linaro but by Suravee working at AMD.
> 
>>
>> *  ARM - SMMU resync of Linux's one (none)
>>   -  Julien Grall
> 
> I think we can put it in: "ok", multiple series has been sent. I expect
> to sent a new version soon.
> 
>>
>> *  ARM - passthrough of non-PCI (none)
>>   -  Julien Grall
> 
> Ditto.
> 
>> *  ARM64 (Cavium Thunder)  PCI passthrough (fair)
> 
> PCI passthrough should be for ARM32 too. I don't see any restrictions
> for having on ARM64 (especially Cavium) support.
> 
>>   -  Manish Jaggi
> 
> I would add an item "GICv3 ITS" done by Vijay Kilari from Cavium.
> 
> Although, while we know they are working on it, I would mark both of
> them as "none" because we didn't see any RFC yet.
> 
>>
>> *  ARM - Remove XEN_DOMCTL_arm_configure_domain band-aid and make it part of 
>> create_domain. (none)
>>   -  Julien Grall
> 
> It has been merged in the "ARM - passthrough of non-PCI" section.
> 
> Regards,
> 


-- 
Julien Grall

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