Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[wei.liu2]

[-- Attachment #1: Type: text/plain, Size: 11179 bytes --]

(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

We are now more than 5 months 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
<=== We are here ===>
* Feature Freeze: 10 Jul 2015
* RCs: TBD
* Release Date: 9 Oct 2015 (could release earlier)

= Reporting blockers =

Note that there is now a blocker section. If you think any bugs / regressions
should become blocker, please reply to this email (but do trim the CC list).

= Requesting for freeze exception =

If you patch series doesn't make it before the freeze, but you think it would
be good for Xen if it's in, you can request for freeze exception.

To request freeze exception, send an email to xen-devel, probably with subject
line "Requesting for freeze exception for FOO".

That email should:
1. clarify the state of patch series / feature.
2. explain why it needs to be in this release (benefits).
3. explain why it doesn't break things (risks).
4. CC relevant maintainers and release manager.

The general rules of thumb of granting freeze exception:
1. the patch series is in shape, only pending a few minor tweaks.
2. the patch series is endorsed by maintainer(s).

There are other criteria that we need to agree on. Those need to be discussed
case by case.

= Missing the freeze =

Some features are going to miss the freeze. You can continue to work on your
patch series and post to xen-devel and hopefully it will be ready to apply once
new development window opens. But as most core maintainers will be focusing on
bug fixes during freeze, turnaround time might be longer.

= 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.

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.

= 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


== Blocker ==

== Hypervisor ==

*  Alternate p2m: support multiple copies of host p2m (ok)
  -  Ed White

*  Improve RTDS scheduler (ok)
   Change RTDS from quantum driven to event driven
  -  Dagaen Golomb, Meng Xu, Chong Li

*  Credit2: introduce per-vcpu soft affinity (good)
  -  Justin T. Weaver

*  Credit2: introduce per-vcpu hard affinity (fair)
  -  Justin T. Weaver

*  sndif: add API for para-virtual sound (fair)
   v7 posted
  -  Oleksandr Dmytryshyn

*  gnttab: improve scalability (good)
  -  David Vrabel

*  Use ticket lock in hypervisor (good)
  -  David Vrabel

*  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

*  Credit2 production ready (none)
   cpu reservation
  -  George Dunlap

*  VM event patches (none)
   Add support for XSETBV vm_events,
   Support hybernating guests
   Support for VMCALL-based vm_events
  -  Razvan Cojocaru

=== Hypervisor X86 ===

*  x86/MSI-X: XSA-120, 128..131 follow-up (ok)
  -  Jan Beulich

*  Intel Cache Allocation Technology (good)
  -  Chao Peng

*  Intel GVT-g (none)
   requires refactoring ioreq-server, fixing 16-byte MMIO emulation
   and optional PV IOMMU support
  -  Yu, Zhang

*  Porting Intel P-state driver to Xen (fair)
  -  Wang, Wei

*  VT-d Posted-interrupt (PI) (good)
   v2 posted
  -  Wu, Feng

*  Support controlling the max C-state sub-state (fair)
   v3 posted
  -  Ross Lagerwall

*  IOMMU ABI for guests to map their DMA regions (fair)
  -  Malcolm Crossley

*  RMRR fix (fair)
   RFC posted
  -  Tiejun Chen

*  VPMU - 'perf' support in Xen (good)
   v21 posted
   Need reviews/final ack.
  -  Boris Ostrovsky

*  PVH domU (fair)
   RFC posted
  -  Elena Ufimtseva

=== Hypervisor ARM ===

*  ITS support (fair )
  -  Vijaya Kumar K

*  Add ACPI support for arm64 on Xen (fair)
   RFC posted
  -  Parth Dixit

*  ARM remote processor iommu module (GPUs + IPUs) (fair)
   v3 posted
  -  Andrii Tseglytskyi

*  ARM VM save/restore/live migration (none)
   Need to rebased against migrationv2 - no code posted.
  -  None

*  ARM GICv2m support (none)
  -  Suravee Suthikulanit

*  ARM PCI passthrough (fair)
  -  Manish Jaggi

*  ARM GICv2 on GICv3 support (none)
  -  Julien Grall
  -  Vijay Kilari

== Xen toolstack ==

*  Split libxc into multiple libraries (fair)
  -  Ian Campbell

*  Migration v2 (libxl) (fair)
  -  Andrew Cooper

*  toolstack-based approach to pvhvm guest kexec (fair)
   also contains hypervisor side change, v6
  -  Vitaly Kuznetsov

*  libxl: cancelling asynchronous operations (fair)
   RFC posted
  -  Ian Jackson

*  VMware tools support (ok)
  -  Don Slutz

*  Blktap2 support (fair)
  -  George Dunlap

*  pvscsi in libxl (fair)
  -  Juergen Gross and Olaf

*  COarse-grain LOck-stepping Virtual Machines in Xen (ok)
   RFC v5 posted
  -  Wen Congyang
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  tmem migrationv2 patches. (none)
  -  Bob Liu & Andrew Cooper & David Vrabel

*  snapshot API extension (checkpointing disk) (fair)
   v10
  -  Chunyan Liu

*  PVH - Migration of PVH DomUs. (none)
   Depends on migration2 code
   v1 posted
  -  Roger Pau Monné

*  PVH - Migration of guests from a PVH dom0  (fair)
   Depends on migration2 code
  -  Roger Pau Monné

== QEMU ==

*  Restrict QEMU
  -  Stefano Stabellini

*  Linux-based QEMU upstream stub domain (fair)
   RFC posted
  -  Eric Shelton

*  Using qemu-upstream in a stubdomain (none)
   Will use rump kernels.
  -  Wei Liu

*  Intel IGD PCI GPU passthrough (ok)
   v5 posted
  -  Chen, Tiejun

== 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)
  -  Julien Grall

== OpenStack ==

== FreeBSD ==

*  PVH FreeBSD dom0 (ok)
   FreeBSD 11 goal. Toolstack side done in Xen 4.5
  -  Roger Pau Monné

== Other OSes (MiniOS, QNX) ==

*  ARM - MiniOS (fair)
   v7 posted
  -  Thomas Leonard

*  PV drivers for automotive kernels (fair)
  -  Artem Mygaiev

== OSSTEST ==

*  OSSTest: libvirt migration (fair)
  -  Wei Liu

*  OSSTest: performance test (fair)
  -  Dario Faggioli

*  CPU pool test case (fair)
  -  Dario Faggioli

*  Add a FreeBSD host (fair)
  -  Roger Pau Monné

*  Nested virt test case

*  v8 posted (fair)
  -  Robert Hu

== Deferred ==

*  HVM USB support in libxl (fair)
   depend on PV USB support
  -  George Dunlap

*  PV USB support in libxl (fair)
  -  Chunyan Liu

*  HT enabled with credit has 7.9 per perf drop. (none)
   kernbench demonstrated it
   http://www.gossamer-threads.com/lists/xen/devel/339409
   This has existed since credit1 introduction.
  -  Dario Faggioli

*  ucode=scan also scan compressed initramfs (none)
  -  Konrad Rzeszutek Wilk

*  adjust log buffer based on memmap size (none)
  -  Konrad Rzeszutek Wilk

*  Further tmem cleanups/fixes (fair)
  -  Bob Liu

*  1TB slow destruction (ok)
  -  Bob Liu

*  cpuid leveling (none)
   http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf
  -  Andrew Cooper

*  Convert tasklet to per-cpu tasklets (fair)
   RFC posted
  -  Konrad Rzeszutek Wilk

*  Xen Boot Information (xbi) (ok)
   Dependency for GRUB2 + EFI work
   http://lists.xen.org/archives/html/xen-devel/2014-10/msg02068.html
   v4, No go for full patchset. Only some of the patches.
   No ARM EFI hardware (yet) available to test them.
  -  Daniel Kiper

*  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

== Completed ==

*  Import xenanalyze in tree (done)
  -  Olaf Hering

*  OSSTest: upgrade to Debian Jessie (none)
  -  Wei Liu

*  OSSTest: stubdom test case (fair)
  -  Wei Liu

*  Remus using migration-v2 (good)
   RFC posted - depends on v6 of 'New Migration'
  -  Yang Hongyang

*  setup CI loop for OpenStack (fair)
  -  Anthony Perard

*  Display IO topology when PXM data is available (good)
   v7 posted
  -  Boris Ostrovsky

*  ARM: reenable support 32-bit userspace running in 64-bit guest (good)
   v2 posted
  -  Ian Campbell

*  Mem_access for ARM (good)
   v15 posted
  -  Tamas K Lengyel

*  Clean-up of mem-event subsystem (good)
   v9 posted
  -  Tamas K Lengyel

*  New Migration (v2). (good)
   v9 (libxc)
   git://xenbits.xen.org/people/andrewcoop/xen.git
   Seems that it might need to slip or we run v1 alongside v2.
  -  Andrew Cooper & David Vrabel

*  libxl: add qxl vga interface support for upstream qemu (fair)
  -  Fabio Fantoni

*  ARM - passthrough of non-PCI (ok)
  -  Julien Grall

*  Intel PML (Page Modification Logging) for Xen (good)
   v1 posted
  -  Kai Huang

*  Regression in PCI passthrough of INTx legacy devices can trigger list corruption (good)
   Sander reported it. Two different types of patches available.
  -  Konrad Rzeszutek Wilk

*  HVM guest NUMA (SRAT) (good)
   See vNUMA in Xen toolstack
  -  Wei Liu

*  vNUMA in Xen toolstack (good)
   v8 posted
  -  Wei Liu

*  Intel memory bandwidth monitoring for VMs (fair)
   v9 posted
  -  Chao Peng

*  ARM - SMMU resync of Linux's one (ok)
  -  Julien Grall

*  Add support for Xilinx ZynqMP SoC (fair)
  -  Edgar E. Iglesias

*  Add support for Huawei hip04-d01 platform (ok)
  -  Frediano Ziglio

*  Thunder X platform support (ok)
  -  Vijay Kilari

*  Splitting off mini-os (done)
  -  Wei Liu

*  OVMF on ARM (done)
   v4 posted
  -  Ard Biesheuvel

*  Update Xen tree to use upstream OVMF (done)
  -  Anthony PERARD

*  Enable vTPM subsystem on TPM 2.0 (done)
  -  Xu, Quan

*  SPICE support improvement (done)
  -  Fabio Fantoni

*  arm: introduce basic Renesas R-Car Gen2 platform support (done)
   v5 posted
  -  Oleksandr Tyshchenko



[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Status of VM event patches (Was: Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble))

[Razvan Cojocaru]

On 06/26/2015 02:16 PM, wei.liu2@citrix.com wrote:
> *  VM event patches (none)
>    Add support for XSETBV vm_events,
>    Support hybernating guests
>    Support for VMCALL-based vm_events
>   -  Razvan Cojocaru

Again, the support for XSETBV vm_events has already been accepted.

V2 of the series has just been discussed today and I plan to submit V3
as early next week as possible.

Of course, it's not my place to judge the probability of the series
making it into the 4.6 release (although I'd obviously be very happy if
it did make it), but I don't think "none" is an accurate description of
the status. :)


Thanks,
Razvan

Re: Status of VM event patches (Was: Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble))

[Julien Grall]

Hi Razvan,

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 26/06/2015 13:27, Razvan Cojocaru wrote:
> On 06/26/2015 02:16 PM, wei.liu2@citrix.com wrote:
>> *  VM event patches (none)
>>     Add support for XSETBV vm_events,
>>     Support hybernating guests
>>     Support for VMCALL-based vm_events
>>    -  Razvan Cojocaru
>
> Again, the support for XSETBV vm_events has already been accepted.
>
> V2 of the series has just been discussed today and I plan to submit V3
> as early next week as possible.
>
> Of course, it's not my place to judge the probability of the series
> making it into the 4.6 release (although I'd obviously be very happy if
> it did make it), but I don't think "none" is an accurate description of
> the status. :)
>
>
> Thanks,
> Razvan
>

-- 
Julien Grall

Re: Status of VM event patches (Was: Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble))

[Razvan Cojocaru]

On 06/26/2015 02:32 PM, Julien Grall wrote:
> Hi Razvan,
> 
> As suggested by Wei on the top of his mail [1], can you please CC only
> relevant people and avoid to reply all?

Of course, sorry.


Thanks,
Razvan

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Vitaly Kuznetsov]

<wei.liu2@citrix.com> 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

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Jan Beulich]

>>> On 26.06.15 at 13:16, <wei.liu2@citrix.com> wrote:
> *  gnttab: improve scalability (good)
>   -  David Vrabel

This went in and passed the push gate already.

Jan

gnttab scalability and ticket locks status

[David Vrabel]

On 26/06/15 12:16, wei.liu2@citrix.com wrote:
> 
> == Blocker == 
> 
> == Hypervisor == 
> 
> *  gnttab: improve scalability (good)
>   -  David Vrabel

This is done.

> *  Use ticket lock in hypervisor (good)
>   -  David Vrabel

This needs the reverts reverting which is currently pending on a kernel
update for ARM.  If the kernel update doesn't turn up soon I think
ticket locks should be re-added anyway since the failure wasn't really
caused by the locking change (the netback bug had always been there).

David

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Andrew Cooper]

On 26/06/15 12:16, wei.liu2@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

Re: gnttab scalability and ticket locks status

[Ian Campbell]

On Fri, 2015-06-26 at 14:49 +0100, David Vrabel wrote:
> On 26/06/15 12:16, wei.liu2@citrix.com wrote:
> > 
> > == Blocker == 
> > 
> > == Hypervisor == 
> > 
> > *  gnttab: improve scalability (good)
> >   -  David Vrabel
> 
> This is done.
> 
> > *  Use ticket lock in hypervisor (good)
> >   -  David Vrabel
> 
> This needs the reverts reverting which is currently pending on a kernel
> update for ARM.  If the kernel update doesn't turn up soon I think
> ticket locks should be re-added anyway since the failure wasn't really
> caused by the locking change (the netback bug had always been there).

As of flight 58875 the kernel is fixed everywhere we care about, I
think.

IOW I can't see a reason not to throw them back in right away.

Ian.

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Daniel Kiper]

On Fri, Jun 26, 2015 at 12:16:56PM +0100, wei.liu2@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

Status of VM event patches (Was: Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble))

[Razvan Cojocaru]

On 06/26/2015 02:16 PM, wei.liu2@citrix.com wrote:
> *  VM event patches (none)
>    Add support for XSETBV vm_events,
>    Support hybernating guests
>    Support for VMCALL-based vm_events
>   -  Razvan Cojocaru

Since V2, there are now 3 more patches that we'd like to see in Xen
mainline at some point:

1. The patch we've originally submitted that computed the current
instruction length in order to be able to skip it completely (instead of
emulating it with dummy nop write operations) has been somewhat
controversial. To that end, we're now computing the instruction length
in the userspace application, and simply send the new EIP back to the HV
in the vm_event reply, so that skipping instructions can work without a
lot of code added to Xen.

2. In the past, we've aways disabled REP optimizations (forcing *reps to
1) when introspection is active. Tamas' work now gates this on
current->domain->arch.mem_access_emulate_enabled in
xen/arch/x86/hvm/emulate.c. A side effect of that is that Windows HVM
guests tend to boot much slower. We'd like to add a dedicated libxc
function that enables / disables this pessimization explicitly.

3. And finally, our ARM team is using the new VMCALL-based hypercall and
have provided a patch that enables the vm_event on ARM. This will
require some work with Tamas since it is my suspicion that there's code
there that should become common between x86 and ARM and has been, at the
moment, more or less copied from x86 (basically xen/arch/arm/event.c and
xen/arch/arm/monitor.c).

The question is, would it be appropriate to add those patches to V3? And
if that's not a problem, how likely is that to affect the current series
getting in before the 4.6 release (that is, assuming that's a realistic
goal, seeing how the feature freeze is two weeks away)? Just trying to
make sure that I go about this the right way.


Thanks,
Razvan

Re: gnttab scalability and ticket locks status

[Jan Beulich]

>>> On 26.06.15 at 16:30, <ian.campbell@citrix.com> wrote:
> On Fri, 2015-06-26 at 14:49 +0100, David Vrabel wrote:
>> On 26/06/15 12:16, wei.liu2@citrix.com wrote:
>> > 
>> > == Blocker == 
>> > 
>> > == Hypervisor == 
>> > 
>> > *  gnttab: improve scalability (good)
>> >   -  David Vrabel
>> 
>> This is done.
>> 
>> > *  Use ticket lock in hypervisor (good)
>> >   -  David Vrabel
>> 
>> This needs the reverts reverting which is currently pending on a kernel
>> update for ARM.  If the kernel update doesn't turn up soon I think
>> ticket locks should be re-added anyway since the failure wasn't really
>> caused by the locking change (the netback bug had always been there).
> 
> As of flight 58875 the kernel is fixed everywhere we care about, I
> think.
> 
> IOW I can't see a reason not to throw them back in right away.

Done.

Jan

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Julien Grall]

On 26/06/2015 13:16, wei.liu2@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

Status of COLO (Was: Xen 4.6 Development Update)

[Yang Hongyang]

On 06/26/2015 07:16 PM, wei.liu2@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)")
>
[...]
>
> == Xen toolstack ==
>
> *  Split libxc into multiple libraries (fair)
>    -  Ian Campbell
>
> *  Migration v2 (libxl) (fair)
>    -  Andrew Cooper
>
[...]
>
> *  COarse-grain LOck-stepping Virtual Machines in Xen (ok)
>     RFC v5 posted

Since v6 got some amount of review comments, and v7 already posted:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03991.html
I think the status should be 'good'

>    -  Wen Congyang
>    -  Gui Jianfeng
>    -  Yang Hongyang
>    -  Dong, Eddie
>
> *  tmem migrationv2 patches. (none)
>    -  Bob Liu & Andrew Cooper & David Vrabel
>
[...]
>
> == Completed ==
>
> *  Import xenanalyze in tree (done)
>    -  Olaf Hering
>
> *  OSSTest: upgrade to Debian Jessie (none)
>    -  Wei Liu
>
> *  OSSTest: stubdom test case (fair)
>    -  Wei Liu
>
> *  Remus using migration-v2 (good)
>     RFC posted - depends on v6 of 'New Migration'
>    -  Yang Hongyang

This state is 'done'.

-- 
Thanks,
Yang.

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Chen, Tiejun]

>
> *  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

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Yu, Zhang]

> = 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
>

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Julien Grall]

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

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Ian Campbell]

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
> 
> 

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Razvan Cojocaru]

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

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1777 bytes --]

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

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Status of VM event patches (Was: Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble))

[Wei Liu]

On Fri, Jun 26, 2015 at 06:23:02PM +0300, Razvan Cojocaru wrote:
> On 06/26/2015 02:16 PM, wei.liu2@citrix.com wrote:
> > *  VM event patches (none)
> >    Add support for XSETBV vm_events,
> >    Support hybernating guests
> >    Support for VMCALL-based vm_events
> >   -  Razvan Cojocaru
> 
> Since V2, there are now 3 more patches that we'd like to see in Xen
> mainline at some point:
> 
> 1. The patch we've originally submitted that computed the current
> instruction length in order to be able to skip it completely (instead of
> emulating it with dummy nop write operations) has been somewhat
> controversial. To that end, we're now computing the instruction length
> in the userspace application, and simply send the new EIP back to the HV
> in the vm_event reply, so that skipping instructions can work without a
> lot of code added to Xen.
> 
> 2. In the past, we've aways disabled REP optimizations (forcing *reps to
> 1) when introspection is active. Tamas' work now gates this on
> current->domain->arch.mem_access_emulate_enabled in
> xen/arch/x86/hvm/emulate.c. A side effect of that is that Windows HVM
> guests tend to boot much slower. We'd like to add a dedicated libxc
> function that enables / disables this pessimization explicitly.
> 
> 3. And finally, our ARM team is using the new VMCALL-based hypercall and
> have provided a patch that enables the vm_event on ARM. This will
> require some work with Tamas since it is my suspicion that there's code
> there that should become common between x86 and ARM and has been, at the
> moment, more or less copied from x86 (basically xen/arch/arm/event.c and
> xen/arch/arm/monitor.c).
> 
> The question is, would it be appropriate to add those patches to V3? And
> if that's not a problem, how likely is that to affect the current series
> getting in before the 4.6 release (that is, assuming that's a realistic
> goal, seeing how the feature freeze is two weeks away)? Just trying to
> make sure that I go about this the right way.
> 

Not speaking from technical point of view but from the time scale point
of view, I don't think you should rush your 3 new patches at this stage.

You sent several patch series. I don't have the expertise or time to
keep track of all of them so I couldn't tell how feasible it is for them
to be ready for 4.6. I tend to say if they are not nearly all acked,
they would need to wait until 4.7.

Wei.

> 
> Thanks,
> Razvan

Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble)

[Wei Liu]

On Fri, Jun 26, 2015 at 02:06:05PM +0200, Vitaly Kuznetsov wrote:
> <wei.liu2@citrix.com> 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

Re: Status of VM event patches (Was: Re: Xen 4.6 Development Update (2 WEEKS TO FREEZE, important information in preamble))

[Razvan Cojocaru]

On 07/06/2015 06:00 PM, Wei Liu wrote:
> On Fri, Jun 26, 2015 at 06:23:02PM +0300, Razvan Cojocaru wrote:
>> On 06/26/2015 02:16 PM, wei.liu2@citrix.com wrote:
>>> *  VM event patches (none)
>>>    Add support for XSETBV vm_events,
>>>    Support hybernating guests
>>>    Support for VMCALL-based vm_events
>>>   -  Razvan Cojocaru
>>
>> Since V2, there are now 3 more patches that we'd like to see in Xen
>> mainline at some point:
>>
>> 1. The patch we've originally submitted that computed the current
>> instruction length in order to be able to skip it completely (instead of
>> emulating it with dummy nop write operations) has been somewhat
>> controversial. To that end, we're now computing the instruction length
>> in the userspace application, and simply send the new EIP back to the HV
>> in the vm_event reply, so that skipping instructions can work without a
>> lot of code added to Xen.
>>
>> 2. In the past, we've aways disabled REP optimizations (forcing *reps to
>> 1) when introspection is active. Tamas' work now gates this on
>> current->domain->arch.mem_access_emulate_enabled in
>> xen/arch/x86/hvm/emulate.c. A side effect of that is that Windows HVM
>> guests tend to boot much slower. We'd like to add a dedicated libxc
>> function that enables / disables this pessimization explicitly.
>>
>> 3. And finally, our ARM team is using the new VMCALL-based hypercall and
>> have provided a patch that enables the vm_event on ARM. This will
>> require some work with Tamas since it is my suspicion that there's code
>> there that should become common between x86 and ARM and has been, at the
>> moment, more or less copied from x86 (basically xen/arch/arm/event.c and
>> xen/arch/arm/monitor.c).
>>
>> The question is, would it be appropriate to add those patches to V3? And
>> if that's not a problem, how likely is that to affect the current series
>> getting in before the 4.6 release (that is, assuming that's a realistic
>> goal, seeing how the feature freeze is two weeks away)? Just trying to
>> make sure that I go about this the right way.
>>
> 
> Not speaking from technical point of view but from the time scale point
> of view, I don't think you should rush your 3 new patches at this stage.
> 
> You sent several patch series. I don't have the expertise or time to
> keep track of all of them so I couldn't tell how feasible it is for them
> to be ready for 4.6. I tend to say if they are not nearly all acked,
> they would need to wait until 4.7.

Of course. Thanks for the reply! Will keep the current series as it is,
and not add anything new (I'll just keep addressing reviews).


Thanks,
Razvan