[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Thanks,
Ravi

>-----Original Message-----
>From: White, Edmund H
>Sent: Wednesday, July 01, 2015 11:09 AM
>To: xen-devel@xxxxxxxxxxxxx
>Cc: Ian Jackson; Jan Beulich; Tim Deegan; Daniel De Graaf; Sahita, Ravi;
>Andrew Cooper; Wei Liu; tlengyel@xxxxxxxxxxx; George Dunlap; White,
>Edmund H
>Subject: [PATCH v3 00/12] Alternate p2m: support multiple copies of host p2m
>
>This set of patches adds support to hvm domains for EPTP switching by
>creating multiple copies of the host p2m (currently limited to 10 copies).
>
>The primary use of this capability is expected to be in scenarios where access
>to memory needs to be monitored and/or restricted below the level at which
>the guest OS page tables operate. Two examples that were discussed at the
>2014 Xen developer summit are:
>
>    VM introspection:
>        http://www.slideshare.net/xen_com_mgr/
>        zero-footprint-guest-memory-introspection-from-xen
>
>    Secure inter-VM communication:
>        http://www.slideshare.net/xen_com_mgr/nakajima-nvf
>
>A more detailed design specification can be found at:
>    http://lists.xenproject.org/archives/html/xen-devel/2015-
>06/msg01319.html
>
>Each p2m copy is populated lazily on EPT violations.
>Permissions for pages in alternate p2m's can be changed in a similar way to
>the existing memory access interface, and gfn->mfn mappings can be
>changed.
>
>All this is done through extra HVMOP types.
>
>The cross-domain HVMOP code has been compile-tested only. Also, the
>cross-domain code is hypervisor-only, the toolstack has not been modified.
>
>The intra-domain code has been tested. Violation notifications can only be
>received for pages that have been modified (access permissions and/or gfn-
>>mfn mapping) intra-domain, and only on VCPU's that have enabled
>notification.
>
>VMFUNC and #VE will both be emulated on hardware without native support.
>
>This code is not compatible with nested hvm functionality and will refuse to
>work with nested hvm active. It is also not compatible with migration. It
>should be considered experimental.
>
>
>Changes since v2:
>
>Addressed all v2 feedback *except*:
>
>    In patch 5, the per-domain EPTP list page is still allocated from the
>    Xen heap. If allocated from the domain heap Xen panics - IIRC on Haswell
>    hardware when walking the EPTP list during exit processing in patch 6.
>
>    HVM_ops are not merged. Tamas suggested merging the memory access
>ops,
>    but in practice they are not as similar as they appear on the surface.
>    Razvan suggested merging the implementation code in p2m.c, but that is
>    also not as common as it appears on the surface.
>    Andrew suggested merging all altp2m ops into one with a subop code in
>    the input stucture. His point that only 255 ops can be defined is well
>    taken, but altp2m uses only 2 more ops than the recently introduced
>    ioreq ops, and <15% of the available ops have been defined. Since we
>    don't know how to implement XSM hooks and policy with the subop model,
>    we have not adopted this suggestion.
>
>    The p2m set/get interface is not modified. The altp2m code needs to
>    write suppress_ve in 2 places and read it in 1 place. The original
>    patch series managed this by coupling the state of suppress_ve to the
>    p2m memory type, which Tim disliked. In v2 of the series, special
>    set/get interaces were added to access suppress_ve only when required.
>    Jan has suggested changing the existing interfaces, but we feel this
>    is inappropriate for this experimental patch series. Changing the
>    existing interfaces would require a design agreement to be reached
>    and would impact a large amount of existing code.
>
>    Andrew kindly added some reviewed-by's to v2. I have not carried
>    his reviewed-by of the memory event patch forward because Tamas
>    requested significant changes to the patch.
>
>
>Changes since v1:
>
>Many changes since v1 in response to maintainer feedback, including:
>
>    Suppress_ve state is now decoupled from memory type
>    VMFUNC emulation handled in x86 emulator
>    Lazy-copy algorithm copies any page where mfn != INVALID_MFN
>    All nested page fault handling except lazy-copy is now in
>        top-level (hvm.c) nested page fault handler
>    Split p2m lock type (as suggested by Tim) to avoid lock order violations
>    XSM hooks
>    Xen parameter to globally enable altp2m (default disabled) and HVM
>parameter
>    Altp2m reference counting no longer uses dirty_cpu bitmap
>    Remapped page tracking to invalidate altp2m's where needed to protect
>Xen
>    Many other minor changes
>
>The altp2m invalidation is implemented to a level that I believe satisifies the
>requirements of protecting Xen. Invalidation notification is not yet
>implemented, and there may be other cases where invalidation is warranted
>to protect the integrity of the restrictions placed through altp2m. We may add
>further patches in this area.
>
>Testability is still a potential issue. We have offered to make our internal
>Windows test binaries available for intra-domain testing. Tamas has been
>working on toolstack support for cross-domain testing with a slightly earlier
>patch series, and we hope he will submit that support.
>
>Not all of the patches will be of interest to everyone copied here. I've copied
>everyone on this initial mailing to give context.
>
>Andrew Cooper (1):
>  common/domain: Helpers to pause a domain while in context
>
>Ed White (10):
>  VMX: VMFUNC and #VE definitions and detection.
>  VMX: implement suppress #VE.
>  x86/HVM: Hardware alternate p2m support detection.
>  x86/altp2m: basic data structures and support routines.
>  VMX/altp2m: add code to support EPTP switching and #VE.
>  x86/altp2m: add control of suppress_ve.
>  x86/altp2m: alternate p2m memory events.
>  x86/altp2m: add remaining support routines.
>  x86/altp2m: define and implement alternate p2m HVMOP types.
>  x86/altp2m: Add altp2mhvm HVM domain parameter.
>
>Ravi Sahita (2):
>  VMX: add VMFUNC leaf 0 (EPTP switching) to emulator.
>  x86/altp2m: XSM hooks for altp2m HVM ops
>
> docs/man/xl.cfg.pod.5                        |  12 +
> docs/misc/xen-command-line.markdown          |   7 +
> tools/flask/policy/policy/modules/xen/xen.if |   4 +-
> tools/libxl/libxl_create.c                   |   1 +
> tools/libxl/libxl_dom.c                      |   2 +
> tools/libxl/libxl_types.idl                  |   1 +
> tools/libxl/xl_cmdimpl.c                     |   8 +
> xen/arch/x86/hvm/Makefile                    |   1 +
> xen/arch/x86/hvm/altp2m.c                    |  92 +++++
> xen/arch/x86/hvm/emulate.c                   |  12 +-
> xen/arch/x86/hvm/hvm.c                       | 327 ++++++++++++++++-
> xen/arch/x86/hvm/vmx/vmcs.c                  |  42 ++-
> xen/arch/x86/hvm/vmx/vmx.c                   | 169 +++++++++
> xen/arch/x86/mm/hap/Makefile                 |   1 +
> xen/arch/x86/mm/hap/altp2m_hap.c             |  98 ++++++
> xen/arch/x86/mm/hap/hap.c                    |  31 +-
> xen/arch/x86/mm/mm-locks.h                   |  38 +-
> xen/arch/x86/mm/p2m-ept.c                    |  68 +++-
> xen/arch/x86/mm/p2m.c                        | 503
>++++++++++++++++++++++++++-
> xen/arch/x86/x86_emulate/x86_emulate.c       |  48 ++-
> xen/arch/x86/x86_emulate/x86_emulate.h       |   4 +
> xen/common/domain.c                          |  28 ++
> xen/common/vm_event.c                        |   3 +
> xen/include/asm-arm/p2m.h                    |   6 +
> xen/include/asm-x86/domain.h                 |  10 +
> xen/include/asm-x86/hvm/altp2m.h             |  42 +++
> xen/include/asm-x86/hvm/hvm.h                |  28 ++
> xen/include/asm-x86/hvm/vcpu.h               |   9 +
> xen/include/asm-x86/hvm/vmx/vmcs.h           |  14 +-
> xen/include/asm-x86/hvm/vmx/vmx.h            |  13 +-
> xen/include/asm-x86/msr-index.h              |   1 +
> xen/include/asm-x86/p2m.h                    |  79 ++++-
> xen/include/public/hvm/hvm_op.h              |  69 ++++
> xen/include/public/hvm/params.h              |   5 +-
> xen/include/public/vm_event.h                |  11 +
> xen/include/xen/sched.h                      |   5 +
> xen/include/xsm/dummy.h                      |  12 +
> xen/include/xsm/xsm.h                        |  12 +
> xen/xsm/dummy.c                              |   2 +
> xen/xsm/flask/hooks.c                        |  12 +
> xen/xsm/flask/policy/access_vectors          |   7 +
> 41 files changed, 1789 insertions(+), 48 deletions(-)  create mode 100644
>xen/arch/x86/hvm/altp2m.c  create mode 100644
>xen/arch/x86/mm/hap/altp2m_hap.c  create mode 100644 xen/include/asm-
>x86/hvm/altp2m.h
>
>--
>1.9.1


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.