Re: [Xen-devel] [PATCH v9 5/5] x86/ioreq server: Synchronously reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.03.17 at 09:28, <kevin.tian@xxxxxxxxx> 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.

Jan


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