Re: [PATCH v4 1/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server.

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

On 6/14/2016 6:04 PM, Jan Beulich wrote:
>>>> On 19.05.16 at 11:05, <yu.c.zhang@linux.intel.com> wrote:
>> @@ -5507,6 +5507,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>>               get_gfn_query_unlocked(d, a.pfn, &t);
>>               if ( p2m_is_mmio(t) )
>>                   a.mem_type =  HVMMEM_mmio_dm;
>> +            else if ( t == p2m_ioreq_server )
>> +                a.mem_type = HVMMEM_ioreq_server;
>>               else if ( p2m_is_readonly(t) )
>>                   a.mem_type =  HVMMEM_ram_ro;
>>               else if ( p2m_is_ram(t) )
> I can see this being suitable to be done here, but ...
>
>> @@ -5537,7 +5539,8 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>>               [HVMMEM_ram_rw]  = p2m_ram_rw,
>>               [HVMMEM_ram_ro]  = p2m_ram_ro,
>>               [HVMMEM_mmio_dm] = p2m_mmio_dm,
>> -            [HVMMEM_unused] = p2m_invalid
>> +            [HVMMEM_unused] = p2m_invalid,
>> +            [HVMMEM_ioreq_server] = p2m_ioreq_server
>>           };
>>   
>>           if ( copy_from_guest(&a, arg, 1) )
> ... how can this be correct without actual handling having got added?
> IOW doesn't at least this change belong into a later patch?

Thanks for your comments. :)
Well, although the new handling logic is in the 3rd patch, we still have 
the old handling code.
Without the other patches, a developer can still use HVMMEM_ioreq_server 
to write-protect
some guest ram pages, and try to handle the write operations on these 
pages with the old
approach - tracking these gfns insid the ioreq server's rangeset.

Thanks
Yu


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