Re: [Xen-devel] Debian Wheezy installer crashes guest when EPT is enabled

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Apr 18, 2014 at 03:17:41PM +0100, Wei Liu wrote:
> On Fri, Apr 18, 2014 at 03:08:04PM +0100, Wei Liu wrote:
> > Hi Jan
> > 
> > I see in the master tree that there are many changes to EPT lately. With
> > the current master tree (as of c82fbfe), I cannot install Debian Wheezy
> > in HVM mode when EPT is enabled. It used to work at d2b4c27.
> > 
> > One particular interesting changeset is aa9114ed ("x86/EPT: force
> > re-evaluation of memory type as necessary"), because I saw the faulting
> > VMEXIT reason to be EXIT_REASON_EPT_MISCONFIG. But I cannot see
> > immediate connection.
> > 
> > The step to reproduce is easy:
> > 0. get an Intel EPT capable machine (I have Xeon X3450)
> > 1. grab Xen master tree and install
> > 2. download debian-7.2.0-amd64-CD-1.iso from any Debian mirror and
> >    install it in HVM mode, with HAP enabled
> > 3. guest crashes soon after installer runs
> > 
> 
> ... and this guest has 5000MB RAM.  If RAM is set to 768MB guest doesn't
> crash.
> 

FWIW I manually bisected the tree. First bad commit:

commit 4d66f069d6abacd392f1301714fdfc64dc92917b
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Thu Apr 10 16:07:17 2014 +0200

    x86: fix pinned cache attribute handling
    
    - make sure UC- is only used for PAT purposes (MTRRs and hence EPT
      don't have this type)
    - add order input to "get", and properly handle conflict case (forcing
      an EPT page split)
    - properly detect (and refuse) overlaps during "set"
    - properly use RCU constructs
    - support deleting ranges through a special type input to "set"
    - set ignore-PAT flag in epte_get_entry_emt() when "get" succeeds
    - set "get" output to ~0 (invalid) rather than 0 (UC) on error (the
      caller shouldn't be looking at it anyway)
    - move struct hvm_mem_pinned_cacheattr_range from header to C file
      (used only there)
    
    Note that the code (before and after this change) implies the GFN
    ranges passed to the hypercall to be inclusive, which is in contrast
    to the sole current user in qemu (all variants). It is not clear to me
    at which layer (qemu, libxc, hypervisor) this would best be fixed.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>


> Wei.

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