Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

s / is page mapped?/ is page unmapped?/ g


On 03/20/2013 11:15 AM, Michael R. Hines wrote:
> OK, can we make a deal? =)
>
> I'm willing to put in the work to perform the dynamic registration on 
> the destination side,
> but let's go a step further and piggy-back on the effort:
>
> We need to couple this registration with a very small modification to 
> save_ram_block():
>
> Currently, save_ram_block does:
>
> 1. is RDMA turned on?      if yes, unconditionally add to next chunk
>                                          (will be made to dynamically 
> register on destination)
> 2. is_dup_page() ?            if yes, skip
> 3. in xbzrle cache?           if yes, skip
> 4. still not sent?                if yes, transmit
>
> I propose adding a "stub" function that adds:
>
> 0. is page mapped?         if yes, skip   (always returns true for now)
> 1. same
> 2. same
> 3. same
> 4. same
>
> Then, later, in a separate patch, I can implement /dev/pagemap support.
>
> When that's done, RDMA dynamic registration will actually take effect and
> benefit from actually verifying that the page is mapped or not.
>
> - Michael
>
>
> On 03/20/2013 09:07 AM, Michael S. Tsirkin wrote:
>> My problem is with the protocol. If it assumes at the protocol level 
>> that everything is pinned down on the destination, we'll have to 
>> rework it all to make it really useful. 
>
>