[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |