qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 2/2] postcopy: Check for shared memory


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v2 2/2] postcopy: Check for shared memory
Date: Thu, 9 Mar 2017 16:06:10 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

* Halil Pasic (address@hidden) wrote:
> 
> 
> On 03/09/2017 02:22 PM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <address@hidden>
> > 
> > Postcopy doesn't support migration of RAM shared with another process
> > yet (we've got a bunch of things to understand).
> > Check for the case and don't allow postcopy to be enabled.
> > 
> > Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> > ---
> >  migration/postcopy-ram.c | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> > 
> > diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
> > index effbeb6..dc80dbb 100644
> > --- a/migration/postcopy-ram.c
> > +++ b/migration/postcopy-ram.c
> > @@ -95,6 +95,19 @@ static bool ufd_version_check(int ufd)
> >      return true;
> >  }
> > 
> > +/* Callback from postcopy_ram_supported_by_host block iterator.
> > + */
> > +static int test_range_shared(const char *block_name, void *host_addr,
> > +                             ram_addr_t offset, ram_addr_t length, void 
> > *opaque)
> > +{
> > +    if (qemu_ram_is_shared(qemu_ram_block_by_name(block_name))) {
> > +        error_report("Postcopy on shared RAM (%s) is not yet supported",
> > +                     block_name);
> > +        return 1;
> > +    }
> > +    return 0;
> > +}
> > +
> 
> Hm, this stuff with the iterator seemed a bit strange (too complicated)
> first, but I'm not familiar with this code. I have no idea why is
> RAMBlockIterFunc
>  
> typedef int (RAMBlockIterFunc)(const char *block_name, void *host_addr,
>     ram_addr_t offset, ram_addr_t length, void *opaque)
> 
> and not 
> 
> typedef int (RAMBlockIterFunc)(RAMBlock *block, void *opaque).
> 
> The reason does not seem to be abstraction.

It is, it's because the contents of RAMBlock are private.

> >  /*
> >   * Note: This has the side effect of munlock'ing all of RAM, that's
> >   * normally fine since if the postcopy succeeds it gets turned back on at 
> > the
> > @@ -127,6 +140,11 @@ bool postcopy_ram_supported_by_host(void)
> >          goto out;
> >      }
> > 
> > +    /* We don't support postcopy with shared RAM yet */
> > +    if (qemu_ram_foreach_block(test_range_shared, NULL)) {
> > +        goto out;
> > +    }
> > +
> 
> But using ram_list directly does not seem to be a good alternative to me,
> and I do not see a third alternative.
> 
> So besides some cosmetic stuff I have nothing to add. Cosmetic stuff is:
> * why range instead of block in test_range_shared
> * I think we could move this up so that we can return directly
> and do not acquire resources which need cleanup
> 
> Regardless of the cosmetics:
> Reviewed-by: Halil Pasic <address@hidden>

Dave

> 
> >      /*
> >       * userfault and mlock don't go together; we'll put it back later if
> >       * it was enabled.
> > 
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]