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

RE: [Xen-devel] [PATCH 07 of 20] Emulation of guest vmptrld



> > +    if ( vmcs_reg == IO_BITMAP_A )
> > +    {
> > +        if (nvmx->iobitmap[0]) {
> > +            unmap_domain_page_global(nvmx->iobitmap[0]);
> > +        }
> > +        gpa = __get_vvmcs(vcpu_nestedhvm(v).nv_vvmcx,
> IO_BITMAP_A);
> > +        mfn = mfn_x(gfn_to_mfn(p2m_get_hostp2m(v->domain),
> > +                              gpa >> PAGE_SHIFT, &p2mt));
> > +        nvmx->iobitmap[0] = map_domain_page_global(mfn);
> 
> Why are these maps _global?  It might be OK to use 2 more global
> mappings per VCPU but the reason should probably go in a comment beside
> the call.

Do you mean to use hvm_map_guest_frame_ro? Fine to me.
> 
> Also, I don't see where these mappings get torn down on domain
> destruction.
> 
Yes. Fixed in nvmx_vcpu_destroy.

> (While I'm looking at this code, this function is quite ugly.  Why have
> a single function if you're going to duplicate its contents anyway?)

??? We don't know fi guest changed the bitmap, so we have to check each time.

> 
> +
> > +    if ( nvcpu->nv_vvmcxaddr == VMCX_EADDR )
> > +    {
> > +        mfn = mfn_x(gfn_to_mfn(p2m_get_hostp2m(v->domain),
> > +                               gpa >> PAGE_SHIFT, &p2mt));
> > +        nvcpu->nv_vvmcx = map_domain_page_global(mfn);
> 
> Again, why _global?

Will fix with hvm_map_guest_frame.

Thx, Eddie



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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