Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
writes: > * toolstack-based approach to pvhvm guest kexec (fair) >also contains hypervisor side change, v6 > - Vitaly Kuznetsov it is already "[PATCH v8 00/11] toolstack-assisted approach to PVHVM guest kexec" waiting for reviews and (IMHO) 'ok' (as I think all major concerns were addressed). The change is fairly isolated from other parts of Xen so it shouldn't bring risks to the release. Thanks, -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
>>> On 26.06.15 at 13:16, wrote: > * gnttab: improve scalability (good) > - David Vrabel This went in and passed the push gate already. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
On 26/06/15 12:16, wei.l...@citrix.com wrote: > == Blocker == The unreversion of ticket locks is, IMO, a blocker to 4.6 The patches are good, and had actually managed to pass the push gate before OSS tripped over an issue exposed by them in netback. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
On Fri, Jun 26, 2015 at 12:16:56PM +0100, wei.l...@citrix.com wrote: [...] > == Blocker == > > == Hypervisor == [...] > * Xen multiboot2-EFI support (ok) >See http://lists.xen.org/archives/html/xen-devel/2015-01/msg03962.html > http://lists.xen.org/archives/html/xen-devel/2015-01/msg03982.html > - Daniel Kiper I have finished all internal work this week. Now I am fully focusing on this project. I taken into account all comments to v1 (there are left few minor things which require some more work but they are not so important at this stage). Currently I am working on Xen early boot code relocatability. I have working PoC but Andrew and Jan have objections in regards to some solutions used in it. It is related to %ebp register usage in general but also command line parsing code. New solutions for these issues have to be found. I am working on it but this is quite difficult. Additionally, GRUB2 code should be reworked. PoC for new functionality works. I think that we are not able to get this stuff into 4.6. All major issues are solved (or at least we have working PoC) but there is not chance that we could have GRUB2 changes accepted in 2 weeks (or at least have them ready due to current work on Xen early boot code relocatability). During Xen Hackathon we agreed that we should not accept Xen changes which require multiboot2 changes which are not in GRUB2 upstream yet. So, first of all we must try to get this changes into upstream and then get Xen patches. Taking into account above, I think that this should not be a blocker for 4.6. This task should be moved to 4.7 (or whatever will be next). I think that at this stage of development inclusion in next release after 4.6 is possible. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
On 26/06/2015 13:16, wei.l...@citrix.com wrote: (Note, please trim your quotes when replying, and also trim the CC list if necessary. You might also consider changing the subject line of your reply to "Status of FOO (Was: Xen 4.6 Development Update (X months reminder)") Hi all Hi Wei, === Hypervisor ARM === [..] * ARM GICv2 on GICv3 support (none) v2 sent. Can be moved to ok - Julien Grall - Vijay Kilari As said on the previous development update, Vijay is not involved to this patch. == Linux == * VPMU - 'perf' support in Linux (ok) Depends on Xen patches Acked by David Vrabel - Boris Ostrovsky * vNUMA in Linux (ok) v6 posted - Wei Liu * COLO Agent in Linux (fair) - Gui Jianfeng - Yang Hongyang - Dong, Eddie * ARM64 - support 64K guest (none) V1 sent. Reworking the code for the v2. It could be moved into (fair). - Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
* RMRR fix (fair) RFC posted Wei, I think this should be ok or good based on current status, and also should remove "RFC" here. Thanks Tiejun ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
= 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 * Intel GVT-g (none) requires refactoring ioreq-server, fixing 16-byte MMIO emulation and optional PV IOMMU support - Yu, Zhang Hi wei, following are status of Intel GVT-g: 1> ioreq-server refactor: fair. patch sent out by me, but not much comments. 2> 16-byte MMIO emulation: I believe status is good, several patch versions sent out by Paul. 3> PV IOMMU: new draft in discussion. Malcolm Crossley has been working on it. So status should be none or fair? Thanks Yu * Porting Intel P-state driver to Xen (fair) - Wang, Wei ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
Hi Tiejun, As suggested by Wei on the top of his mail [1], can you please CC only relevant people and avoid to reply all? Many thanks, [1] (Note, please trim your quotes when replying, and also trim the CC list if necessary. You might also consider changing the subject line of your reply to "Status of FOO (Was: Xen 4.6 Development Update (X months reminder)") On 01/07/15 07:12, Chen, Tiejun wrote: >> >> * RMRR fix (fair) >> RFC posted > > Wei, > > I think this should be ok or good based on current status, and also > should remove "RFC" here. > > Thanks > Tiejun > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
On Wed, 2015-07-01 at 11:17 +0100, Julien Grall wrote: > As suggested by Wei on the top of his mail [1], can you please CC only > relevant people and avoid to reply all? It seems that many people are unable to follow these simple instructions. Wei, perhaps you could stop CCing people who inappropriately do not trim their quotes or the CC list in the future. If they cannot do us the courtesy of doing so I don't see why they should receive a courtesy copy of the status mail. A somewhat less aggressive approach might be to use Bcc instead Cc for the bulk of people (i.e. anyone who needn't be cc-d on every reply). The failure case of someone who cannot read simple instructions then becomes a lack of CCs rather than a plethora of unwanted Ccs. Ian. > > Many thanks, > > [1] (Note, please trim your quotes when replying, and also trim the CC > list if > necessary. You might also consider changing the subject line of your > reply to > "Status of FOO (Was: Xen 4.6 Development Update (X months reminder)") > > On 01/07/15 07:12, Chen, Tiejun wrote: > >> > >> * RMRR fix (fair) > >> RFC posted > > > > Wei, > > > > I think this should be ok or good based on current status, and also > > should remove "RFC" here. > > > > Thanks > > Tiejun > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
Hello Ian, Julien, On 07/02/2015 11:35 AM, Ian Campbell wrote: > On Wed, 2015-07-01 at 11:17 +0100, Julien Grall wrote: >> As suggested by Wei on the top of his mail [1], can you please CC only >> relevant people and avoid to reply all? > > It seems that many people are unable to follow these simple > instructions. > > Wei, perhaps you could stop CCing people who inappropriately do not trim > their quotes or the CC list in the future. If they cannot do us the > courtesy of doing so I don't see why they should receive a courtesy copy > of the status mail. > > A somewhat less aggressive approach might be to use Bcc instead Cc for > the bulk of people (i.e. anyone who needn't be cc-d on every reply). The > failure case of someone who cannot read simple instructions then becomes > a lack of CCs rather than a plethora of unwanted Ccs. First of all, let me apologize for doing this in the past, I'll certainly remember to not let it happen again. Second, I'd like to point out that, while I cannot speak for everyone, and so maybe it's just me, I find this statement: "please trim your quotes when replying, and also trim the CC list if necessary" a bit ambiguous. The quotes part is obvious (and not that many people have ommited to do that), but to be honest I haven't been clear on who is supposed to be in the trimmed CC list: the maintainers of the code I'm touching with my series and Wei? There doesn't seem to be a clear rule about who should be replied to (or maybe there is and I've missed it? If so, could you please point it out?). Maybe clearing this up could help with this problem in the future. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
On Thu, 2015-07-02 at 11:51 +0300, Razvan Cojocaru wrote: > On 07/02/2015 11:35 AM, Ian Campbell wrote: > > It seems that many people are unable to follow these simple > > instructions. > > The quotes part is obvious (and not that many people have ommited to do > that), but to be honest I haven't been clear on who is supposed to be in > the trimmed CC list: the maintainers of the code I'm touching with my > series and Wei? > Exactly. It's the 'interested parties' that should be Cc-ed, which, 99% of the times, is exactly what you just said: - the maintainers because, well, they are the maintainers, they know the code, they most likely know your series and will be able to engage in a conversation on whether the estimation is correct or not; - the release manager, since we're discussing release; - there might me more people, such as, people that have been involved in the review process, despite not being maintainers, or... no, that's all that comes to my mind. So, trim to such a set, and you'll make most of the people happy, I bet. > There doesn't seem to be a clear rule about who should > be replied to (or maybe there is and I've missed it? If so, could you > please point it out?). Maybe clearing this up could help with this > problem in the future. > I think it was pretty obvious. I guess it would not harm to add a line making this crystal clear in the mail, but it's Wei's call to judge whether that is really necessary. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)
On Fri, Jun 26, 2015 at 02:06:05PM +0200, Vitaly Kuznetsov wrote: > writes: > > > * toolstack-based approach to pvhvm guest kexec (fair) > >also contains hypervisor side change, v6 > > - Vitaly Kuznetsov > > it is already "[PATCH v8 00/11] toolstack-assisted approach to > PVHVM guest kexec" waiting for reviews and (IMHO) 'ok' (as I think all > major concerns were addressed). The change is fairly isolated from > other parts of Xen so it shouldn't bring risks to the release. > The HV side patches are mostly not acked, i.e. they are not yet ready. I'm sorry this series is not going to make 4.6 from my point of view. :-/ Wei. > Thanks, > > -- > Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
