> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, March 22, 2017 4:54 PM > > >>> On 22.03.17 at 09:28, <kevin.t...@intel.com> wrote: > >> From: Yu Zhang > >> Sent: Tuesday, March 21, 2017 10:53 AM > >> --- a/xen/arch/x86/hvm/dm.c > >> +++ b/xen/arch/x86/hvm/dm.c > >> @@ -385,16 +385,51 @@ static int dm_op(domid_t domid, > >> > >> case XEN_DMOP_map_mem_type_to_ioreq_server: > >> { > >> - const struct xen_dm_op_map_mem_type_to_ioreq_server *data = > >> + struct xen_dm_op_map_mem_type_to_ioreq_server *data = > >> &op.u.map_mem_type_to_ioreq_server; > >> + unsigned long first_gfn = data->opaque; > >> + unsigned long last_gfn; > >> + > >> + const_op = false; > >> > >> rc = -EOPNOTSUPP; > >> /* Only support for HAP enabled hvm. */ > >> if ( !hap_enabled(d) ) > >> break; > >> > >> - rc = hvm_map_mem_type_to_ioreq_server(d, data->id, > >> - data->type, data->flags); > >> + if ( first_gfn == 0 ) > >> + rc = hvm_map_mem_type_to_ioreq_server(d, data->id, > >> + data->type, > >> data->flags); > >> + /* > >> + * Iterate p2m table when an ioreq server unmaps from > >> p2m_ioreq_server, > >> + * and reset the remaining p2m_ioreq_server entries back to > >> p2m_ram_rw. > >> + */ > > > > can you elaborate how device model is expected to use this new > > extension, i.e. on deciding first_gfn? > > The device model doesn't decide anything here (hence the field's name being > "opaque"), it simply has to pass zero for correct operation. >
Got it. It's for hypercall continuation. :-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
