Re: [PATCH v3 1/2] Differentiate IO/mem resources tracked by ioreq server

["Yu, Zhang" <yu.c.zhang@linux.intel.com>]

On 8/10/2015 4:26 PM, Wei Liu wrote:
> On Mon, Aug 10, 2015 at 11:33:40AM +0800, Yu Zhang wrote:
>> Currently in ioreq server, guest write-protected ram pages are
>> tracked in the same rangeset with device mmio resources. Yet
>> unlike device mmio, which can be in big chunks, the guest write-
>> protected pages may be discrete ranges with 4K bytes each.
>>
>> This patch uses a seperate rangeset for the guest ram pages.
>> And a new ioreq type, IOREQ_TYPE_MEM, is defined.
>>
>> Note: Previously, a new hypercall or subop was suggested to map
>> write-protected pages into ioreq server. However, it turned out
>> handler of this new hypercall would be almost the same with the
>> existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's
>> already a type parameter in this hypercall. So no new hypercall
>> defined, only a new type is introduced.
>>
>> Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com>
>> ---
>>   tools/libxc/include/xenctrl.h    | 39 +++++++++++++++++++++++---
>>   tools/libxc/xc_domain.c          | 59 ++++++++++++++++++++++++++++++++++++++--
>
> FWIW the hypercall wrappers look correct to me.
>
>> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
>> index 014546a..9106cb9 100644
>> --- a/xen/include/public/hvm/hvm_op.h
>> +++ b/xen/include/public/hvm/hvm_op.h
>> @@ -329,8 +329,9 @@ struct xen_hvm_io_range {
>>       ioservid_t id;               /* IN - server id */
>>       uint32_t type;               /* IN - type of range */
>>   # define HVMOP_IO_RANGE_PORT   0 /* I/O port range */
>> -# define HVMOP_IO_RANGE_MEMORY 1 /* MMIO range */
>> +# define HVMOP_IO_RANGE_MMIO   1 /* MMIO range */
>>   # define HVMOP_IO_RANGE_PCI    2 /* PCI segment/bus/dev/func range */
>> +# define HVMOP_IO_RANGE_MEMORY 3 /* MEMORY range */
>
> This looks problematic. Maybe you can get away with this because this is
> a toolstack-only interface?
>
Thanks Wei.
Well, I believe this interface could be used both by the backend device
driver and qemu as well(which I neglected).  :-)

Yu

> Wei.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>