Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

On 3/21/2017 9:18 AM, Yu Zhang wrote: On 3/21/2017 1:03 AM, Jan Beulich wrote: On 18.03.17 at 11:53, wrote: --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla,

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

On 3/21/2017 1:03 AM, Jan Beulich wrote: On 18.03.17 at 11:53, wrote: --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long gla, (npfec.write_access &&

Re: [Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

>>> On 18.03.17 at 11:53, wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -1870,18 +1870,14 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned > long gla, > (npfec.write_access && >(p2m_is_discard_write(p2mt) ||

[Xen-devel] [PATCH v8 1/5] x86/ioreq server: Release the p2m lock after mmio is handled.

Routine hvmemul_do_io() may need to peek the p2m type of a gfn to select the ioreq server. For example, operations on gfns with p2m_ioreq_server type will be delivered to a corresponding ioreq server, and this requires that the p2m type not be switched back to p2m_ram_rw during the emulation