Re: [Xen-devel] [PATCH 08/11] x86/altp2m: add remaining support routines.

[Tim Deegan <tim@xxxxxxx>]

At 12:57 -0800 on 15 Jan (1421323048), Ed White wrote:
> On 01/15/2015 09:25 AM, Tim Deegan wrote:
> > Hi,
> > 
> > At 13:26 -0800 on 09 Jan (1420806398), Ed White wrote:
> >> +int
> >> +altp2mhvm_hap_nested_page_fault(struct vcpu *v, paddr_t gpa,
> >> +                                unsigned long gla, struct npfec npfec)
> >> +{
> >> +    struct domain *d = v->domain;
> >> +    struct p2m_domain *hp2m = p2m_get_hostp2m(d);
> >> +    struct p2m_domain *ap2m;
> >> +    p2m_type_t p2mt;
> >> +    p2m_access_t p2ma;
> >> +    unsigned int page_order;
> >> +    unsigned long gfn, mask;
> >> +    mfn_t mfn;
> >> +    int rv;
> >> +
> >> +    ap2m = p2m_get_altp2m(v);
> >> +
> >> +    mfn = get_gfn_type_access(ap2m, gpa >> PAGE_SHIFT, &p2mt, &p2ma,
> >> +                              0, &page_order);
> >> +    __put_gfn(ap2m, gpa >> PAGE_SHIFT);
> >> +
> >> +    if ( mfn_valid(mfn) )
> >> +    {
> >> +        /* Should #VE be emulated for this fault? */
> >> +        if ( p2mt == p2m_ram_rw_ve && !cpu_has_vmx_virt_exceptions &&
> >> +             ahvm_vcpu_emulate_ve(v) )
> >> +            return ALTP2MHVM_PAGEFAULT_DONE;
> >> +
> >> +        /* Could not handle fault here */
> >> +        gdprintk(XENLOG_INFO, "Altp2m memory access permissions failure, "
> >> +                              "no mem_event listener VCPU %d, dom %d\n",
> >> +                              v->vcpu_id, d->domain_id);
> >> +        domain_crash(v->domain);
> >> +        return ALTP2MHVM_PAGEFAULT_CONTINUE;
> >> +    }
> >> +
> >> +    mfn = get_gfn_type_access(hp2m, gpa >> PAGE_SHIFT, &p2mt, &p2ma,
> >> +                              0, &page_order);
> >> +    put_gfn(hp2m->domain, gpa >> PAGE_SHIFT);
> >> +
> >> +    if ( p2mt != p2m_ram_rw || p2ma != p2m_access_rwx )
> >> +        return ALTP2MHVM_PAGEFAULT_CONTINUE;
> > 
> > I don't follow -- surely the altp2m ought to contain everything that's
> > in the host p2m except for deliberate extra changes.  But it looks
> > like here you just bail on anything other than rwx RAM.  That's going
> > to livelock on anything that the main fault handler thinks is OK to retry.
> 
> It sounds like there must be some cases that I'm not aware of.
> 
> I've only tested Windows, and I've never seen anything other than rwx ram
> where the hardware is ever able to retry and succeed. That's why I don't
> copy anything else to the alternate p2m, because my experience has been
> that everything else can be resolved in the host p2m and its nested page
> fault handler. As I explained to Jan, if the host p2m page becomes rwx ram
> and *then* there's a retry, I copy that EPTE on the violation that the retry
> triggers and retry again.
> 
> I want to get this right. Can you tell me what I'm missing?

I think the easiest case to test would be read access to a read-only
area (e.g., I think, the in-VM BIOS).  PCI passthrough will have the
same problem with p2m_mmio_diirect mappings of BARs.

In those cases the hostp2m has a valid mapping that it expects the
guest can use, but it's not rwx.

I think there would be a similr problem with anything that mem_even
caller had marked non-execute or read-only in the host p2m.

Cheers,

Tim.


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