All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Alexey Perevalov <a.perevalov@samsung.com>
Cc: Peter Xu <peterx@redhat.com>,
	i.maximets@samsung.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V6 04/10] migration: split ufd_version_check onto receive/request features part
Date: Wed, 31 May 2017 20:12:59 +0100	[thread overview]
Message-ID: <20170531191258.GH3342@work-vm> (raw)
In-Reply-To: <d4289a31-5661-dcfc-ca08-e7af2eb57ba1@samsung.com>

* Alexey Perevalov (a.perevalov@samsung.com) wrote:
> On 05/24/2017 02:33 PM, Peter Xu wrote:
> > On Wed, May 24, 2017 at 09:45:48AM +0300, Alexey wrote:
> > 
> > [...]
> > 
> > > > >           return false;
> > > > >       }
> > > > > -    ioctl_mask = (__u64)1 << _UFFDIO_REGISTER |
> > > > > -                 (__u64)1 << _UFFDIO_UNREGISTER;
> > > > > +    ioctl_mask = 1 << _UFFDIO_REGISTER |
> > > > > +                 1 << _UFFDIO_UNREGISTER;
> > > > Could I ask why we explicitly removed (__u64) here? Since I see the
> > > > old one better.
> > > maybe my change not robust, in any case thank to point me, but now I
> > > think, here should be a constant instead of ioctl_mask, like
> > > UFFD_API_IOCTLS, the total meaning of that check it's make sure kernel
> > > returns to us no error and accepted features.
> > > ok, from the beginning:
> > > 
> > > if we request unsupported feature (we check it before) or internal
> > > state of userfault ctx inside kernel isn't UFFD_STATE_WAIT_API (for
> > > example we are in the middle of the coping process)
> > > 	ioctl should end with EINVAL error and ioctls field in
> > > 	uffdio_api will be empty
> > > 
> > > Right now I think ioctls check for UFFD_API is not necessary.
> > > We just say here, we will use _UFFDIO_REGISTER, _UFFDIO_UNREGISTER,
> > > but kernel supports it unconditionally, by contrast with
> > > UFFDIO_REGISTER ioctl - it also returns ioctl field in uffdio_register
> > > structure, here can be a variations.
> > Sorry I didn't get the point...
> I misprinted
> >We just say here, we will use _UFFDIO_REGISTER
> 
> > s/_UFFDIO_REGISTER/_UFFDIO_API/g
> but the point, ioctl_mask is not necessary here, kernel always returns it.
> But for _UFFDIO_UNREGISTER, later, not in this function, yes that check is required.

But Peter's only point was that to build the mask it's better to keep
the (__u64) cast for safety.

Dave

> > 
> > AFAIU here (__u64) makes the constant "1" a 64bit variable. Just like
> > when we do bit shift we normally have "1ULL<<40". I liked it since
> > even if _UFFDIO_REGISTER is defined as >32 it will not overflow since
> > by default a constant "1" is a "int" typed (and it's 32bit width).
> 
> > Thanks,
> > 
> 
> -- 
> Best regards,
> Alexey Perevalov
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2017-05-31 19:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170523113120eucas1p2032ace2121aa8627067b6d7f03fbf482@eucas1p2.samsung.com>
2017-05-23 11:31 ` [Qemu-devel] [PATCH V6 00/10] calculate blocktime for postcopy live migration Alexey Perevalov
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 01/10] userfault: add pid into uffd_msg & update UFFD_FEATURE_* Alexey Perevalov
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 02/10] migration: pass MigrationIncomingState* into migration check functions Alexey Perevalov
2017-05-31 17:54     ` Dr. David Alan Gilbert
2017-06-05  5:59       ` Alexey Perevalov
2017-06-05  9:15         ` Dr. David Alan Gilbert
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 03/10] migration: fix hardcoded function name in error report Alexey Perevalov
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 04/10] migration: split ufd_version_check onto receive/request features part Alexey Perevalov
2017-05-24  2:36     ` Peter Xu
2017-05-24  6:45       ` Alexey
2017-05-24 11:33         ` Peter Xu
2017-05-24 11:47           ` Alexey Perevalov
2017-05-31 19:12             ` Dr. David Alan Gilbert [this message]
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 05/10] migration: introduce postcopy-blocktime capability Alexey Perevalov
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 06/10] migration: add postcopy blocktime ctx into MigrationIncomingState Alexey Perevalov
2017-05-24  3:31     ` Peter Xu
2017-06-05  6:31       ` Alexey Perevalov
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 07/10] migration: add bitmap for copied page Alexey Perevalov
2017-05-24  6:57     ` Peter Xu
2017-05-24  7:56       ` Alexey
2017-05-24 12:01         ` Peter Xu
2017-05-24 12:16           ` Alexey Perevalov
2017-05-24 23:30             ` Peter Xu
2017-05-25  6:28               ` Alexey Perevalov
2017-05-25  7:25                 ` Peter Xu
2017-05-31 19:25                   ` Dr. David Alan Gilbert
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 08/10] migration: calculate vCPU blocktime on dst side Alexey Perevalov
2017-05-24  7:53     ` Peter Xu
2017-05-24  9:37       ` Alexey
2017-05-24 11:22         ` Peter Xu
2017-05-24 11:37           ` Alexey Perevalov
2017-06-01 10:07           ` Dr. David Alan Gilbert
2017-06-01 10:50         ` Dr. David Alan Gilbert
2017-06-01 10:57     ` Dr. David Alan Gilbert
2017-06-07  7:34       ` Alexey Perevalov
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 09/10] migration: add postcopy total blocktime into query-migrate Alexey Perevalov
2017-06-01 11:35     ` Dr. David Alan Gilbert
2017-05-23 11:31   ` [Qemu-devel] [PATCH V6 10/10] migration: postcopy_blocktime documentation Alexey Perevalov
2017-06-01 11:37     ` Dr. David Alan Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170531191258.GH3342@work-vm \
    --to=dgilbert@redhat.com \
    --cc=a.perevalov@samsung.com \
    --cc=i.maximets@samsung.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.