Re: [Xen-devel] [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jul 08, 2015 at 06:35:33PM +0000, Sahita, Ravi wrote:
> Hi Wei,
> 
> Given where we stand (close) on the altp2m patch series - we would like to 
> request an extension of about a week to complete the last couple of patches 
> in the series for inclusion in 4.6. 
> Some of the suggestions may have implications on other patches and on our 
> tests hence asking for the extension (we know what we need to change). 
> 
> Hope that is acceptable. This is a quick current status snapshot of v3: 
> (this doesn't have a couple tools patches that Tamas has contributed but 
> those will be included in rev4)
> 
> altp2m series patch v3 status
> 0     [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m     
>                         Sign-off        Reviewed                Acked         
>           Status
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 1     [Xen-devel] [PATCH v3 01/13] common/domain: Helpers to pause a domain 
> while in context  Andrew Cooper                                           
> good?
> 2     [Xen-devel] [PATCH v3 02/13] VMX: VMFUNC and #VE definitions and 
> detection.             Ed White        Andrew Cooper   Jun Nakajima           
>  good
> 3     [Xen-devel] [PATCH v3 03/13] VMX: implement suppress #VE.               
>                         Ed White        Andrew Cooper   Jun Nakajima          
>   good
> 4     [Xen-devel] [PATCH v3 04/13] x86/HVM: Hardware alternate p2m support 
> detection          Ed White        Andrew Cooper                           
> good?
> 5     [Xen-devel] [PATCH v3 05/13] x86/altp2m: basic data structures and 
> support routines             Ed White        Andrew Cooper                    
>        Locking being reviewed by George Dunlap
> 6     [Xen-devel] [PATCH v3 06/13] VMX/altp2m: add code to support EPTP 
> switching and #VE     Ed White        Andrew Cooper   Jun Nakajima            
> good
> 7     [Xen-devel] [PATCH v3 07/13] VMX: add VMFUNC leaf 0 (EPTP switching) to 
> emulator                Ravi Sahita     ***                                   
>           ***Proposed Changes ready staged for v4
> 8     [Xen-devel] [PATCH v3 08/13] x86/altp2m: add control of suppress_ve     
>                         Ed White        ***Andrew Cooper                      
>           *** George Dunlap has an alt patch based on v2 7 of 12
> 9     [Xen-devel] [PATCH v3 09/13] x86/altp2m: alternate p2m memory events    
>                 Ed White        Andrew Cooper   George Dunlap           good
> 10    [Xen-devel] [PATCH v3 10/13] x86/altp2m: add remaining support routines 
>                 Ed White        Andew Cooper                                  
>   good?
> 11    [Xen-devel] [PATCH v3 11/13] x86/altp2m: define and implement alternate 
> p2m HVMOP type  Ed White        ***                                           
>   *** Need to create HVMOP sub-types for altp2m
> 12    [Xen-devel] [PATCH v3 12/13] x86/altp2m: Add altp2mhvm HVM domain 
> parameter             Ed White        Andew Cooper                            
>         Wei's comments addressed and staged for v4
> 13    [Xen-devel] [PATCH v3 13/13] x86/altp2m: XSM hooks for altp2m HVM ops   
>                 Ravi Sahita     Daniel De Graaf         Daniel De Graaf       
>   *** Will be impacted by HVMOP changes
> 

Hi Ravi

Thanks for the email. Let me elaborate on this.

First thing, you asked for an freeze extension, but as I understand it
you meant a freeze exception. I will reply on this basis.

Overall the series is of very high quality and very useful feature,
personally I would very much like this feature to be accepted in 4.6,
but I did set out criteria for granting a freeze exception [0]. The
series in question needs to be in a state that's only pending a few
tweaks and publicly endorsed by maintainers, plus other case by case
consideration.

With my limited knowledge of hypervisor side code I can't tell if the
series is very close. But some very long sub-threads prompt me into
thinking there are still issues (big or small).

As far as I can tell, there are several issues here with regard to this
patch series on hypervisor side:

1. Patch #1 is neither acked nor reviewed.

2. Patch #5, George is looking at locking scheme. Although that patch
   is already reviewed by Andrew and locking scheme backed by Tim, I
   would like a formal ack from George as current P2M maintainer.

3. Patch #7 has issue with regard to instruction emulator.

4. Patch #8 in this version (#7 in previous version, v2) is reviewed,
   but I'm not sure if the concern raised in v2 went away. Judging
   from the date of v3 submission and date of issue raised on v2, the
   issue is still there.

5. Patch #11 is not acked, and because it's ABI matter we need to be
   very careful about it.

6. Patch #13 will be affected by HVM op changes. A new ack is required
   in version 4.

I would need all above issues addressed to consider granting a freeze
exception. I can't speak for hypervisor maintainers. They could ack
your next version, or they could raise more issues.

With my tools maintainer hat on, I think the tools side changes in v3
are trivial and in theory I should be able to just ack it in version
4. I don't think having more patches on tools side is a good idea. The
ideal situation of patches accepted in the first round is rather
low. I would suggest if you post those patches you arrange them at the
end of your series, so that if we can apply all those acked patches if
a freeze exception is granted.

Question for you and Ed, how much testing have you done to this
series? I assume you've done testing with it turned on and off, to the
point you get a functioning guest. Have you run any test suites and
got positive results?

Question for hypervisor maintainers, how much risk do you think this
series impose?  If this feature is off, is the code path more or less
the same of before?  It seems to touch core functionality (P2M). Note
that any bug in that area would block the release.

I do have a hard line in mind -- the freeze exception should be
granted in the first week of the freeze (this seems to match your
estimation). I won't consider granting any after that time frame.

All in all, I can't grant this series freeze exception now but I also
don't preclude the possibility of doing that.

Wei.

[0]: <E1Z8Rcu-0003v6-7l@xxxxxxxxxxxxxxxxxxxxxxxx>

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