[Qemu-devel] [PATCH v2 0/4] memfd fixes.

[Qemu-devel] [PATCH v2 0/4] memfd fixes.

[Ilya Maximets]

Version 2:
    * First patch changed to just drop the memfd backend
      if seals are not supported.

Ilya Maximets (4):
  hostmem-memfd: disable for systems wihtout sealing support
  memfd: always check for MFD_CLOEXEC
  memfd: set up correct errno if not supported
  memfd: improve error messages

 backends/hostmem-memfd.c | 18 ++++++++----------
 tests/vhost-user-test.c  |  6 +++---
 util/memfd.c             | 10 ++++++++--
 3 files changed, 19 insertions(+), 15 deletions(-)

-- 
2.17.1

[Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Ilya Maximets]

If seals are not supported, memfd_create() will fail.
Furthermore, there is no way to disable it in this case because
'.seal' property is not registered.

This issue leads to vhost-user-test failures on RHEL 7.2:

  qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
                      failed to create memfd: Invalid argument

and actually breaks the feature on such systems.

Let's restrict memfd backend to systems with sealing support.

Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
---
 backends/hostmem-memfd.c | 18 ++++++++----------
 tests/vhost-user-test.c  |  6 +++---
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
index b6836b28e5..a3455da9c9 100644
--- a/backends/hostmem-memfd.c
+++ b/backends/hostmem-memfd.c
@@ -156,15 +156,13 @@ memfd_backend_class_init(ObjectClass *oc, void *data)
                                               "Huge pages size (ex: 2M, 1G)",
                                               &error_abort);
     }
-    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
-        object_class_property_add_bool(oc, "seal",
-                                       memfd_backend_get_seal,
-                                       memfd_backend_set_seal,
-                                       &error_abort);
-        object_class_property_set_description(oc, "seal",
-                                              "Seal growing & shrinking",
-                                              &error_abort);
-    }
+    object_class_property_add_bool(oc, "seal",
+                                   memfd_backend_get_seal,
+                                   memfd_backend_set_seal,
+                                   &error_abort);
+    object_class_property_set_description(oc, "seal",
+                                          "Seal growing & shrinking",
+                                          &error_abort);
 }
 
 static const TypeInfo memfd_backend_info = {
@@ -177,7 +175,7 @@ static const TypeInfo memfd_backend_info = {
 
 static void register_types(void)
 {
-    if (qemu_memfd_check(0)) {
+    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
         type_register_static(&memfd_backend_info);
     }
 }
diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c
index 45d58d8ea2..e3e9a33580 100644
--- a/tests/vhost-user-test.c
+++ b/tests/vhost-user-test.c
@@ -169,7 +169,7 @@ static char *get_qemu_cmd(TestServer *s,
                           int mem, enum test_memfd memfd, const char *mem_path,
                           const char *chr_opts, const char *extra)
 {
-    if (memfd == TEST_MEMFD_AUTO && qemu_memfd_check(0)) {
+    if (memfd == TEST_MEMFD_AUTO && qemu_memfd_check(MFD_ALLOW_SEALING)) {
         memfd = TEST_MEMFD_YES;
     }
 
@@ -903,7 +903,7 @@ static void test_multiqueue(void)
     s->queues = 2;
     test_server_listen(s);
 
-    if (qemu_memfd_check(0)) {
+    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
         cmd = g_strdup_printf(
             QEMU_CMD_MEMFD QEMU_CMD_CHR QEMU_CMD_NETDEV ",queues=%d "
             "-device virtio-net-pci,netdev=net0,mq=on,vectors=%d",
@@ -963,7 +963,7 @@ int main(int argc, char **argv)
     /* run the main loop thread so the chardev may operate */
     thread = g_thread_new(NULL, thread_function, loop);
 
-    if (qemu_memfd_check(0)) {
+    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
         qtest_add_data_func("/vhost-user/read-guest-mem/memfd",
                             GINT_TO_POINTER(TEST_MEMFD_YES),
                             test_read_guest_mem);
-- 
2.17.1

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Marc-André Lureau]

Hi
On Tue, Nov 27, 2018 at 5:50 PM Ilya Maximets <i.maximets@samsung.com> wrote:
>
> If seals are not supported, memfd_create() will fail.
> Furthermore, there is no way to disable it in this case because
> '.seal' property is not registered.
>
> This issue leads to vhost-user-test failures on RHEL 7.2:
>
>   qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
>                       failed to create memfd: Invalid argument
>
> and actually breaks the feature on such systems.
>
> Let's restrict memfd backend to systems with sealing support.
>
> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>

Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>

thanks

> ---
>  backends/hostmem-memfd.c | 18 ++++++++----------
>  tests/vhost-user-test.c  |  6 +++---
>  2 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
> index b6836b28e5..a3455da9c9 100644
> --- a/backends/hostmem-memfd.c
> +++ b/backends/hostmem-memfd.c
> @@ -156,15 +156,13 @@ memfd_backend_class_init(ObjectClass *oc, void *data)
>                                                "Huge pages size (ex: 2M, 1G)",
>                                                &error_abort);
>      }
> -    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
> -        object_class_property_add_bool(oc, "seal",
> -                                       memfd_backend_get_seal,
> -                                       memfd_backend_set_seal,
> -                                       &error_abort);
> -        object_class_property_set_description(oc, "seal",
> -                                              "Seal growing & shrinking",
> -                                              &error_abort);
> -    }
> +    object_class_property_add_bool(oc, "seal",
> +                                   memfd_backend_get_seal,
> +                                   memfd_backend_set_seal,
> +                                   &error_abort);
> +    object_class_property_set_description(oc, "seal",
> +                                          "Seal growing & shrinking",
> +                                          &error_abort);
>  }
>
>  static const TypeInfo memfd_backend_info = {
> @@ -177,7 +175,7 @@ static const TypeInfo memfd_backend_info = {
>
>  static void register_types(void)
>  {
> -    if (qemu_memfd_check(0)) {
> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>          type_register_static(&memfd_backend_info);
>      }
>  }
> diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c
> index 45d58d8ea2..e3e9a33580 100644
> --- a/tests/vhost-user-test.c
> +++ b/tests/vhost-user-test.c
> @@ -169,7 +169,7 @@ static char *get_qemu_cmd(TestServer *s,
>                            int mem, enum test_memfd memfd, const char *mem_path,
>                            const char *chr_opts, const char *extra)
>  {
> -    if (memfd == TEST_MEMFD_AUTO && qemu_memfd_check(0)) {
> +    if (memfd == TEST_MEMFD_AUTO && qemu_memfd_check(MFD_ALLOW_SEALING)) {
>          memfd = TEST_MEMFD_YES;
>      }
>
> @@ -903,7 +903,7 @@ static void test_multiqueue(void)
>      s->queues = 2;
>      test_server_listen(s);
>
> -    if (qemu_memfd_check(0)) {
> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>          cmd = g_strdup_printf(
>              QEMU_CMD_MEMFD QEMU_CMD_CHR QEMU_CMD_NETDEV ",queues=%d "
>              "-device virtio-net-pci,netdev=net0,mq=on,vectors=%d",
> @@ -963,7 +963,7 @@ int main(int argc, char **argv)
>      /* run the main loop thread so the chardev may operate */
>      thread = g_thread_new(NULL, thread_function, loop);
>
> -    if (qemu_memfd_check(0)) {
> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>          qtest_add_data_func("/vhost-user/read-guest-mem/memfd",
>                              GINT_TO_POINTER(TEST_MEMFD_YES),
>                              test_read_guest_mem);
> --
> 2.17.1
>

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Igor Mammedov]

On Tue, 27 Nov 2018 16:50:27 +0300
Ilya Maximets <i.maximets@samsung.com> wrote:

s/wihtout/without/ in subj

> If seals are not supported, memfd_create() will fail.
> Furthermore, there is no way to disable it in this case because
> '.seal' property is not registered.
> 
> This issue leads to vhost-user-test failures on RHEL 7.2:
> 
>   qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
>                       failed to create memfd: Invalid argument
> 
> and actually breaks the feature on such systems.
> 
> Let's restrict memfd backend to systems with sealing support.
> 
> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
> ---
>  backends/hostmem-memfd.c | 18 ++++++++----------
>  tests/vhost-user-test.c  |  6 +++---
>  2 files changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
> index b6836b28e5..a3455da9c9 100644
> --- a/backends/hostmem-memfd.c
> +++ b/backends/hostmem-memfd.c
> @@ -156,15 +156,13 @@ memfd_backend_class_init(ObjectClass *oc, void *data)
>                                                "Huge pages size (ex: 2M, 1G)",
>                                                &error_abort);
>      }
> -    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
> -        object_class_property_add_bool(oc, "seal",
> -                                       memfd_backend_get_seal,
> -                                       memfd_backend_set_seal,
> -                                       &error_abort);
> -        object_class_property_set_description(oc, "seal",
> -                                              "Seal growing & shrinking",
> -                                              &error_abort);
> -    }
> +    object_class_property_add_bool(oc, "seal",
> +                                   memfd_backend_get_seal,
> +                                   memfd_backend_set_seal,
> +                                   &error_abort);
> +    object_class_property_set_description(oc, "seal",
> +                                          "Seal growing & shrinking",
> +                                          &error_abort);
>  }
>  
>  static const TypeInfo memfd_backend_info = {
> @@ -177,7 +175,7 @@ static const TypeInfo memfd_backend_info = {
>  
>  static void register_types(void)
>  {
> -    if (qemu_memfd_check(0)) {
> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>          type_register_static(&memfd_backend_info);
that would either lead to not clear error that type doesn't exist.
it could be better to report sensible error from memfd_backend_memory_alloc() if
the feature is required but not supported by host 

>      }
>  }
> diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c
> index 45d58d8ea2..e3e9a33580 100644
> --- a/tests/vhost-user-test.c
> +++ b/tests/vhost-user-test.c
> @@ -169,7 +169,7 @@ static char *get_qemu_cmd(TestServer *s,
>                            int mem, enum test_memfd memfd, const char *mem_path,
>                            const char *chr_opts, const char *extra)
>  {
> -    if (memfd == TEST_MEMFD_AUTO && qemu_memfd_check(0)) {
> +    if (memfd == TEST_MEMFD_AUTO && qemu_memfd_check(MFD_ALLOW_SEALING)) {
>          memfd = TEST_MEMFD_YES;
>      }
>  
> @@ -903,7 +903,7 @@ static void test_multiqueue(void)
>      s->queues = 2;
>      test_server_listen(s);
>  
> -    if (qemu_memfd_check(0)) {
> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>          cmd = g_strdup_printf(
>              QEMU_CMD_MEMFD QEMU_CMD_CHR QEMU_CMD_NETDEV ",queues=%d "
>              "-device virtio-net-pci,netdev=net0,mq=on,vectors=%d",
> @@ -963,7 +963,7 @@ int main(int argc, char **argv)
>      /* run the main loop thread so the chardev may operate */
>      thread = g_thread_new(NULL, thread_function, loop);
>  
> -    if (qemu_memfd_check(0)) {
> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>          qtest_add_data_func("/vhost-user/read-guest-mem/memfd",
>                              GINT_TO_POINTER(TEST_MEMFD_YES),
>                              test_read_guest_mem);

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Ilya Maximets]

On 10.12.2018 19:18, Igor Mammedov wrote:
> On Tue, 27 Nov 2018 16:50:27 +0300
> Ilya Maximets <i.maximets@samsung.com> wrote:
> 
> s/wihtout/without/ in subj
> 
>> If seals are not supported, memfd_create() will fail.
>> Furthermore, there is no way to disable it in this case because
>> '.seal' property is not registered.
>>
>> This issue leads to vhost-user-test failures on RHEL 7.2:
>>
>>   qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
>>                       failed to create memfd: Invalid argument
>>
>> and actually breaks the feature on such systems.
>>
>> Let's restrict memfd backend to systems with sealing support.
>>
>> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
>> ---
>>  backends/hostmem-memfd.c | 18 ++++++++----------
>>  tests/vhost-user-test.c  |  6 +++---
>>  2 files changed, 11 insertions(+), 13 deletions(-)
>>
>> diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
>> index b6836b28e5..a3455da9c9 100644
>> --- a/backends/hostmem-memfd.c
>> +++ b/backends/hostmem-memfd.c
>> @@ -156,15 +156,13 @@ memfd_backend_class_init(ObjectClass *oc, void *data)
>>                                                "Huge pages size (ex: 2M, 1G)",
>>                                                &error_abort);
>>      }
>> -    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>> -        object_class_property_add_bool(oc, "seal",
>> -                                       memfd_backend_get_seal,
>> -                                       memfd_backend_set_seal,
>> -                                       &error_abort);
>> -        object_class_property_set_description(oc, "seal",
>> -                                              "Seal growing & shrinking",
>> -                                              &error_abort);
>> -    }
>> +    object_class_property_add_bool(oc, "seal",
>> +                                   memfd_backend_get_seal,
>> +                                   memfd_backend_set_seal,
>> +                                   &error_abort);
>> +    object_class_property_set_description(oc, "seal",
>> +                                          "Seal growing & shrinking",
>> +                                          &error_abort);
>>  }
>>  
>>  static const TypeInfo memfd_backend_info = {
>> @@ -177,7 +175,7 @@ static const TypeInfo memfd_backend_info = {
>>  
>>  static void register_types(void)
>>  {
>> -    if (qemu_memfd_check(0)) {
>> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>>          type_register_static(&memfd_backend_info);
> that would either lead to not clear error that type doesn't exist.
> it could be better to report sensible error from memfd_backend_memory_alloc() if
> the feature is required but not supported by host 

I'm not sure, but this could break the libvirt capability discovering.

Current patch changes behaviour probably only for RHEL/CentOS 7.2.
All other systems are not affected. Do you think that we need to
change behaviour on all the systems?

> 
>>      }
>>  }
>> diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c
>> index 45d58d8ea2..e3e9a33580 100644
>> --- a/tests/vhost-user-test.c
>> +++ b/tests/vhost-user-test.c
>> @@ -169,7 +169,7 @@ static char *get_qemu_cmd(TestServer *s,
>>                            int mem, enum test_memfd memfd, const char *mem_path,
>>                            const char *chr_opts, const char *extra)
>>  {
>> -    if (memfd == TEST_MEMFD_AUTO && qemu_memfd_check(0)) {
>> +    if (memfd == TEST_MEMFD_AUTO && qemu_memfd_check(MFD_ALLOW_SEALING)) {
>>          memfd = TEST_MEMFD_YES;
>>      }
>>  
>> @@ -903,7 +903,7 @@ static void test_multiqueue(void)
>>      s->queues = 2;
>>      test_server_listen(s);
>>  
>> -    if (qemu_memfd_check(0)) {
>> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>>          cmd = g_strdup_printf(
>>              QEMU_CMD_MEMFD QEMU_CMD_CHR QEMU_CMD_NETDEV ",queues=%d "
>>              "-device virtio-net-pci,netdev=net0,mq=on,vectors=%d",
>> @@ -963,7 +963,7 @@ int main(int argc, char **argv)
>>      /* run the main loop thread so the chardev may operate */
>>      thread = g_thread_new(NULL, thread_function, loop);
>>  
>> -    if (qemu_memfd_check(0)) {
>> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>>          qtest_add_data_func("/vhost-user/read-guest-mem/memfd",
>>                              GINT_TO_POINTER(TEST_MEMFD_YES),
>>                              test_read_guest_mem);
> 
> 
> 

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Igor Mammedov]

On Tue, 11 Dec 2018 13:29:19 +0300
Ilya Maximets <i.maximets@samsung.com> wrote:

CCing libvirt folk for an opinion

> On 10.12.2018 19:18, Igor Mammedov wrote:
> > On Tue, 27 Nov 2018 16:50:27 +0300
> > Ilya Maximets <i.maximets@samsung.com> wrote:
> > 
> > s/wihtout/without/ in subj
> >   
> >> If seals are not supported, memfd_create() will fail.
> >> Furthermore, there is no way to disable it in this case because
> >> '.seal' property is not registered.
> >>
> >> This issue leads to vhost-user-test failures on RHEL 7.2:
> >>
> >>   qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
> >>                       failed to create memfd: Invalid argument
> >>
> >> and actually breaks the feature on such systems.
> >>
> >> Let's restrict memfd backend to systems with sealing support.
> >>
[...]
> >> @@ -177,7 +175,7 @@ static const TypeInfo memfd_backend_info = {
> >>  
> >>  static void register_types(void)
> >>  {
> >> -    if (qemu_memfd_check(0)) {
> >> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
> >>          type_register_static(&memfd_backend_info);  
> > that would either lead to not clear error that type doesn't exist.
> > it could be better to report sensible error from memfd_backend_memory_alloc() if
> > the feature is required but not supported by host   
> 
> I'm not sure, but this could break the libvirt capability discovering.
> 
> Current patch changes behaviour probably only for RHEL/CentOS 7.2.
> All other systems are not affected. Do you think that we need to
> change behaviour on all the systems?
you are changing behavior anyways, so when users start getting
on some of 'All other systems' start getting 'type doesn't exist'
error, they won't have a clue what's wrong. In case where we are
fixing broken defaults, shouldn't we at least do it the way that
would inform user about misconfiguration.

But I'm not insisting since memfd is fairly new, it might be fine
for device to just disappear.

[...]

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Eduardo Habkost]

On Tue, Dec 11, 2018 at 04:48:23PM +0100, Igor Mammedov wrote:
> On Tue, 11 Dec 2018 13:29:19 +0300
> Ilya Maximets <i.maximets@samsung.com> wrote:
> 
> CCing libvirt folk for an opinion
> 
> > On 10.12.2018 19:18, Igor Mammedov wrote:
> > > On Tue, 27 Nov 2018 16:50:27 +0300
> > > Ilya Maximets <i.maximets@samsung.com> wrote:
> > > 
> > > s/wihtout/without/ in subj
> > >   
> > >> If seals are not supported, memfd_create() will fail.
> > >> Furthermore, there is no way to disable it in this case because
> > >> '.seal' property is not registered.
> > >>
> > >> This issue leads to vhost-user-test failures on RHEL 7.2:
> > >>
> > >>   qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
> > >>                       failed to create memfd: Invalid argument
> > >>
> > >> and actually breaks the feature on such systems.
> > >>
> > >> Let's restrict memfd backend to systems with sealing support.
> > >>
> [...]
> > >> @@ -177,7 +175,7 @@ static const TypeInfo memfd_backend_info = {
> > >>  
> > >>  static void register_types(void)
> > >>  {
> > >> -    if (qemu_memfd_check(0)) {
> > >> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
> > >>          type_register_static(&memfd_backend_info);  
> > > that would either lead to not clear error that type doesn't exist.
> > > it could be better to report sensible error from memfd_backend_memory_alloc() if
> > > the feature is required but not supported by host   
> > 
> > I'm not sure, but this could break the libvirt capability discovering.
> > 
> > Current patch changes behaviour probably only for RHEL/CentOS 7.2.
> > All other systems are not affected. Do you think that we need to
> > change behaviour on all the systems?
> you are changing behavior anyways, so when users start getting
> on some of 'All other systems' start getting 'type doesn't exist'
> error, they won't have a clue what's wrong. In case where we are
> fixing broken defaults, shouldn't we at least do it the way that
> would inform user about misconfiguration.
> 
> But I'm not insisting since memfd is fairly new, it might be fine
> for device to just disappear.

(Sorry for taking so long to reply on this series.  I couldn't
review the code yet.)

I'd like to make the QOM type hierarchy static, and not depend on
any runtime host capability checks.  But this is not a new
problem in the code, so I don't think it should block this
series.

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Ilya Maximets]

So, can we have any conclusion about this patch and the series?

Best regards, Ilya Maximets.

On 05.01.2019 5:43, Eduardo Habkost wrote:
> On Tue, Dec 11, 2018 at 04:48:23PM +0100, Igor Mammedov wrote:
>> On Tue, 11 Dec 2018 13:29:19 +0300
>> Ilya Maximets <i.maximets@samsung.com> wrote:
>>
>> CCing libvirt folk for an opinion
>>
>>> On 10.12.2018 19:18, Igor Mammedov wrote:
>>>> On Tue, 27 Nov 2018 16:50:27 +0300
>>>> Ilya Maximets <i.maximets@samsung.com> wrote:
>>>>
>>>> s/wihtout/without/ in subj
>>>>   
>>>>> If seals are not supported, memfd_create() will fail.
>>>>> Furthermore, there is no way to disable it in this case because
>>>>> '.seal' property is not registered.
>>>>>
>>>>> This issue leads to vhost-user-test failures on RHEL 7.2:
>>>>>
>>>>>   qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
>>>>>                       failed to create memfd: Invalid argument
>>>>>
>>>>> and actually breaks the feature on such systems.
>>>>>
>>>>> Let's restrict memfd backend to systems with sealing support.
>>>>>
>> [...]
>>>>> @@ -177,7 +175,7 @@ static const TypeInfo memfd_backend_info = {
>>>>>  
>>>>>  static void register_types(void)
>>>>>  {
>>>>> -    if (qemu_memfd_check(0)) {
>>>>> +    if (qemu_memfd_check(MFD_ALLOW_SEALING)) {
>>>>>          type_register_static(&memfd_backend_info);  
>>>> that would either lead to not clear error that type doesn't exist.
>>>> it could be better to report sensible error from memfd_backend_memory_alloc() if
>>>> the feature is required but not supported by host   
>>>
>>> I'm not sure, but this could break the libvirt capability discovering.
>>>
>>> Current patch changes behaviour probably only for RHEL/CentOS 7.2.
>>> All other systems are not affected. Do you think that we need to
>>> change behaviour on all the systems?
>> you are changing behavior anyways, so when users start getting
>> on some of 'All other systems' start getting 'type doesn't exist'
>> error, they won't have a clue what's wrong. In case where we are
>> fixing broken defaults, shouldn't we at least do it the way that
>> would inform user about misconfiguration.
>>
>> But I'm not insisting since memfd is fairly new, it might be fine
>> for device to just disappear.
> 
> (Sorry for taking so long to reply on this series.  I couldn't
> review the code yet.)
> 
> I'd like to make the QOM type hierarchy static, and not depend on
> any runtime host capability checks.  But this is not a new
> problem in the code, so I don't think it should block this
> series.
> 

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Daniel P. Berrangé]

On Tue, Nov 27, 2018 at 04:50:27PM +0300, Ilya Maximets wrote:
> If seals are not supported, memfd_create() will fail.
> Furthermore, there is no way to disable it in this case because
> '.seal' property is not registered.

Isn't the real problem here that memfd_backend_instance_init() has
unconditionally set  "m->seal = true"

Surely, if we don't register the '.seal' property, we should default
that flag to false.

> 
> This issue leads to vhost-user-test failures on RHEL 7.2:
> 
>   qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
>                       failed to create memfd: Invalid argument
> 
> and actually breaks the feature on such systems.
> 
> Let's restrict memfd backend to systems with sealing support.

I don't think we need todo that - sealing is optional in the QEMU code,
we simply have it set to the wrong default when sealing is not available.

> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Ilya Maximets]

On 11.12.2018 13:53, Daniel P. Berrangé wrote:
> On Tue, Nov 27, 2018 at 04:50:27PM +0300, Ilya Maximets wrote:
>> If seals are not supported, memfd_create() will fail.
>> Furthermore, there is no way to disable it in this case because
>> '.seal' property is not registered.
> 
> Isn't the real problem here that memfd_backend_instance_init() has
> unconditionally set  "m->seal = true"
> 
> Surely, if we don't register the '.seal' property, we should default
> that flag to false.
> 
>>
>> This issue leads to vhost-user-test failures on RHEL 7.2:
>>
>>   qemu-system-x86_64: -object memory-backend-memfd,id=mem,size=2M,: \
>>                       failed to create memfd: Invalid argument
>>
>> and actually breaks the feature on such systems.
>>
>> Let's restrict memfd backend to systems with sealing support.
> 
> I don't think we need todo that - sealing is optional in the QEMU code,
> we simply have it set to the wrong default when sealing is not available.

That was literally what I've fixed in v1:
    https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html

but 2 people suggested me to disable memfd entirely for this case.
Do you think I need to get patch from v1 back ?

Gerd, Marc-André, what do you think?

> 
>> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
> 
> 
> Regards,
> Daniel
> 

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Gerd Hoffmann]

On Tue, Dec 11, 2018 at 02:09:11PM +0300, Ilya Maximets wrote:
> On 11.12.2018 13:53, Daniel P. Berrangé wrote:
> >>
> >> Let's restrict memfd backend to systems with sealing support.
> > 
> > I don't think we need todo that - sealing is optional in the QEMU code,
> > we simply have it set to the wrong default when sealing is not available.
> 
> That was literally what I've fixed in v1:
>     https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html
> 
> but 2 people suggested me to disable memfd entirely for this case.
> Do you think I need to get patch from v1 back ?
> 
> Gerd, Marc-André, what do you think?

I still think it makes sense to require sealing support.  Sealing is
very useful, and there are only a few kernel versions with memfd but
without sealing.  So finding such kernels in the wild will become more
rare over time.  I wouldn't worry too much about them.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Eduardo Habkost]

On Wed, Dec 12, 2018 at 07:49:36AM +0100, Gerd Hoffmann wrote:
> On Tue, Dec 11, 2018 at 02:09:11PM +0300, Ilya Maximets wrote:
> > On 11.12.2018 13:53, Daniel P. Berrangé wrote:
> > >>
> > >> Let's restrict memfd backend to systems with sealing support.
> > > 
> > > I don't think we need todo that - sealing is optional in the QEMU code,
> > > we simply have it set to the wrong default when sealing is not available.
> > 
> > That was literally what I've fixed in v1:
> >     https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html
> > 
> > but 2 people suggested me to disable memfd entirely for this case.
> > Do you think I need to get patch from v1 back ?
> > 
> > Gerd, Marc-André, what do you think?
> 
> I still think it makes sense to require sealing support.  Sealing is
> very useful, and there are only a few kernel versions with memfd but
> without sealing.  So finding such kernels in the wild will become more
> rare over time.  I wouldn't worry too much about them.

-object memory-backend-memfd,id=mem,size=2M,seal=off still
works on those systems, doesn't it?  What's the rationale for
breaking a working configuration without following the
deprecation policy?

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Ilya Maximets]

On 16.01.2019 18:30, Eduardo Habkost wrote:
> On Wed, Dec 12, 2018 at 07:49:36AM +0100, Gerd Hoffmann wrote:
>> On Tue, Dec 11, 2018 at 02:09:11PM +0300, Ilya Maximets wrote:
>>> On 11.12.2018 13:53, Daniel P. Berrangé wrote:
>>>>>
>>>>> Let's restrict memfd backend to systems with sealing support.
>>>>
>>>> I don't think we need todo that - sealing is optional in the QEMU code,
>>>> we simply have it set to the wrong default when sealing is not available.
>>>
>>> That was literally what I've fixed in v1:
>>>     https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html
>>>
>>> but 2 people suggested me to disable memfd entirely for this case.
>>> Do you think I need to get patch from v1 back ?
>>>
>>> Gerd, Marc-André, what do you think?
>>
>> I still think it makes sense to require sealing support.  Sealing is
>> very useful, and there are only a few kernel versions with memfd but
>> without sealing.  So finding such kernels in the wild will become more
>> rare over time.  I wouldn't worry too much about them.
> 
> -object memory-backend-memfd,id=mem,size=2M,seal=off still
> works on those systems, doesn't it?  What's the rationale for
> breaking a working configuration without following the
> deprecation policy?
> 

See the commit message.
'.seal' property is not registered if sealing is not supported.
So, there is no way to disable sealing on the system that does not support it.

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Daniel P. Berrangé]

On Wed, Jan 16, 2019 at 06:46:39PM +0300, Ilya Maximets wrote:
> 
> 
> On 16.01.2019 18:30, Eduardo Habkost wrote:
> > On Wed, Dec 12, 2018 at 07:49:36AM +0100, Gerd Hoffmann wrote:
> >> On Tue, Dec 11, 2018 at 02:09:11PM +0300, Ilya Maximets wrote:
> >>> On 11.12.2018 13:53, Daniel P. Berrangé wrote:
> >>>>>
> >>>>> Let's restrict memfd backend to systems with sealing support.
> >>>>
> >>>> I don't think we need todo that - sealing is optional in the QEMU code,
> >>>> we simply have it set to the wrong default when sealing is not available.
> >>>
> >>> That was literally what I've fixed in v1:
> >>>     https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html
> >>>
> >>> but 2 people suggested me to disable memfd entirely for this case.
> >>> Do you think I need to get patch from v1 back ?
> >>>
> >>> Gerd, Marc-André, what do you think?
> >>
> >> I still think it makes sense to require sealing support.  Sealing is
> >> very useful, and there are only a few kernel versions with memfd but
> >> without sealing.  So finding such kernels in the wild will become more
> >> rare over time.  I wouldn't worry too much about them.
> > 
> > -object memory-backend-memfd,id=mem,size=2M,seal=off still
> > works on those systems, doesn't it?  What's the rationale for
> > breaking a working configuration without following the
> > deprecation policy?
> > 
> 
> See the commit message.
> '.seal' property is not registered if sealing is not supported.
> So, there is no way to disable sealing on the system that does not support it.

As I pointed out a few lines up, this is simply because QEMU has a bug
setting seal=true as the built-in default value even when it isn't
supported. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Ilya Maximets]

On 16.01.2019 18:48, Daniel P. Berrangé wrote:
> On Wed, Jan 16, 2019 at 06:46:39PM +0300, Ilya Maximets wrote:
>>
>>
>> On 16.01.2019 18:30, Eduardo Habkost wrote:
>>> On Wed, Dec 12, 2018 at 07:49:36AM +0100, Gerd Hoffmann wrote:
>>>> On Tue, Dec 11, 2018 at 02:09:11PM +0300, Ilya Maximets wrote:
>>>>> On 11.12.2018 13:53, Daniel P. Berrangé wrote:
>>>>>>>
>>>>>>> Let's restrict memfd backend to systems with sealing support.
>>>>>>
>>>>>> I don't think we need todo that - sealing is optional in the QEMU code,
>>>>>> we simply have it set to the wrong default when sealing is not available.
>>>>>
>>>>> That was literally what I've fixed in v1:
>>>>>     https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html
>>>>>
>>>>> but 2 people suggested me to disable memfd entirely for this case.
>>>>> Do you think I need to get patch from v1 back ?
>>>>>
>>>>> Gerd, Marc-André, what do you think?
>>>>
>>>> I still think it makes sense to require sealing support.  Sealing is
>>>> very useful, and there are only a few kernel versions with memfd but
>>>> without sealing.  So finding such kernels in the wild will become more
>>>> rare over time.  I wouldn't worry too much about them.
>>>
>>> -object memory-backend-memfd,id=mem,size=2M,seal=off still
>>> works on those systems, doesn't it?  What's the rationale for
>>> breaking a working configuration without following the
>>> deprecation policy?
>>>
>>
>> See the commit message.
>> '.seal' property is not registered if sealing is not supported.
>> So, there is no way to disable sealing on the system that does not support it.
> 
> As I pointed out a few lines up, this is simply because QEMU has a bug
> setting seal=true as the built-in default value even when it isn't
> supported. 

So, do you think I need to return to the solution from my v1:
  https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html

?

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Daniel P. Berrangé]

On Wed, Jan 16, 2019 at 06:54:38PM +0300, Ilya Maximets wrote:
> On 16.01.2019 18:48, Daniel P. Berrangé wrote:
> > On Wed, Jan 16, 2019 at 06:46:39PM +0300, Ilya Maximets wrote:
> >>
> >>
> >> On 16.01.2019 18:30, Eduardo Habkost wrote:
> >>> On Wed, Dec 12, 2018 at 07:49:36AM +0100, Gerd Hoffmann wrote:
> >>>> On Tue, Dec 11, 2018 at 02:09:11PM +0300, Ilya Maximets wrote:
> >>>>> On 11.12.2018 13:53, Daniel P. Berrangé wrote:
> >>>>>>>
> >>>>>>> Let's restrict memfd backend to systems with sealing support.
> >>>>>>
> >>>>>> I don't think we need todo that - sealing is optional in the QEMU code,
> >>>>>> we simply have it set to the wrong default when sealing is not available.
> >>>>>
> >>>>> That was literally what I've fixed in v1:
> >>>>>     https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html
> >>>>>
> >>>>> but 2 people suggested me to disable memfd entirely for this case.
> >>>>> Do you think I need to get patch from v1 back ?
> >>>>>
> >>>>> Gerd, Marc-André, what do you think?
> >>>>
> >>>> I still think it makes sense to require sealing support.  Sealing is
> >>>> very useful, and there are only a few kernel versions with memfd but
> >>>> without sealing.  So finding such kernels in the wild will become more
> >>>> rare over time.  I wouldn't worry too much about them.
> >>>
> >>> -object memory-backend-memfd,id=mem,size=2M,seal=off still
> >>> works on those systems, doesn't it?  What's the rationale for
> >>> breaking a working configuration without following the
> >>> deprecation policy?
> >>>
> >>
> >> See the commit message.
> >> '.seal' property is not registered if sealing is not supported.
> >> So, there is no way to disable sealing on the system that does not support it.
> > 
> > As I pointed out a few lines up, this is simply because QEMU has a bug
> > setting seal=true as the built-in default value even when it isn't
> > supported. 
> 
> So, do you think I need to return to the solution from my v1:
>   https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html

That is my preference, but we don't have  universal agreement :-(

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v2 1/4] hostmem-memfd: disable for systems wihtout sealing support

[Eduardo Habkost]

On Wed, Jan 16, 2019 at 03:48:57PM +0000, Daniel P. Berrangé wrote:
> On Wed, Jan 16, 2019 at 06:46:39PM +0300, Ilya Maximets wrote:
> > 
> > 
> > On 16.01.2019 18:30, Eduardo Habkost wrote:
> > > On Wed, Dec 12, 2018 at 07:49:36AM +0100, Gerd Hoffmann wrote:
> > >> On Tue, Dec 11, 2018 at 02:09:11PM +0300, Ilya Maximets wrote:
> > >>> On 11.12.2018 13:53, Daniel P. Berrangé wrote:
> > >>>>>
> > >>>>> Let's restrict memfd backend to systems with sealing support.
> > >>>>
> > >>>> I don't think we need todo that - sealing is optional in the QEMU code,
> > >>>> we simply have it set to the wrong default when sealing is not available.
> > >>>
> > >>> That was literally what I've fixed in v1:
> > >>>     https://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg05483.html
> > >>>
> > >>> but 2 people suggested me to disable memfd entirely for this case.
> > >>> Do you think I need to get patch from v1 back ?
> > >>>
> > >>> Gerd, Marc-André, what do you think?
> > >>
> > >> I still think it makes sense to require sealing support.  Sealing is
> > >> very useful, and there are only a few kernel versions with memfd but
> > >> without sealing.  So finding such kernels in the wild will become more
> > >> rare over time.  I wouldn't worry too much about them.
> > > 
> > > -object memory-backend-memfd,id=mem,size=2M,seal=off still
> > > works on those systems, doesn't it?  What's the rationale for
> > > breaking a working configuration without following the
> > > deprecation policy?
> > > 
> > 
> > See the commit message.
> > '.seal' property is not registered if sealing is not supported.
> > So, there is no way to disable sealing on the system that does not support it.
> 
> As I pointed out a few lines up, this is simply because QEMU has a bug
> setting seal=true as the built-in default value even when it isn't
> supported. 

Changing to seal=false by default may make it work on some hosts,
but I don't see the point of increasing our support burden just
for a few kernel versions.  I agree with Gerd, I think it's
simpler to keep it unsupported.

-- 
Eduardo

[Qemu-devel] [PATCH v2 2/4] memfd: always check for MFD_CLOEXEC

[Ilya Maximets]

QEMU always sets this flag unconditionally. We need to
check if it's supported.

Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 util/memfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/util/memfd.c b/util/memfd.c
index 8debd0d037..d74ce4d793 100644
--- a/util/memfd.c
+++ b/util/memfd.c
@@ -188,7 +188,7 @@ bool qemu_memfd_alloc_check(void)
 bool qemu_memfd_check(unsigned int flags)
 {
 #ifdef CONFIG_LINUX
-    int mfd = memfd_create("test", flags);
+    int mfd = memfd_create("test", flags | MFD_CLOEXEC);
 
     if (mfd >= 0) {
         close(mfd);
-- 
2.17.1

[Qemu-devel] [PATCH v2 3/4] memfd: set up correct errno if not supported

[Ilya Maximets]

qemu_memfd_create() prints the value of 'errno' which is not
set in this case.

Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 util/memfd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/util/memfd.c b/util/memfd.c
index d74ce4d793..393d23da96 100644
--- a/util/memfd.c
+++ b/util/memfd.c
@@ -40,6 +40,7 @@ static int memfd_create(const char *name, unsigned int flags)
 #ifdef __NR_memfd_create
     return syscall(__NR_memfd_create, name, flags);
 #else
+    errno = ENOSYS;
     return -1;
 #endif
 }
-- 
2.17.1

[Qemu-devel] [PATCH v2 4/4] memfd: improve error messages

[Ilya Maximets]

This gives more information about the failure.
Additionally 'ENOSYS' returned for a non-Linux platforms instead of
'errno', which is not initilaized in this case.

Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 util/memfd.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/util/memfd.c b/util/memfd.c
index 393d23da96..00334e5b21 100644
--- a/util/memfd.c
+++ b/util/memfd.c
@@ -71,14 +71,18 @@ int qemu_memfd_create(const char *name, size_t size, bool hugetlb,
     }
     mfd = memfd_create(name, flags);
     if (mfd < 0) {
+        error_setg_errno(errp, errno,
+                         "failed to create memfd with flags 0x%x", flags);
         goto err;
     }
 
     if (ftruncate(mfd, size) == -1) {
+        error_setg_errno(errp, errno, "failed to resize memfd to %zu", size);
         goto err;
     }
 
     if (seals && fcntl(mfd, F_ADD_SEALS, seals) == -1) {
+        error_setg_errno(errp, errno, "failed to add seals 0x%x", seals);
         goto err;
     }
 
@@ -88,8 +92,9 @@ err:
     if (mfd >= 0) {
         close(mfd);
     }
+#else
+    error_setg_errno(errp, ENOSYS, "failed to create memfd");
 #endif
-    error_setg_errno(errp, errno, "failed to create memfd");
     return -1;
 }
 
-- 
2.17.1

Re: [Qemu-devel] [PATCH v2 0/4] memfd fixes.

[Ilya Maximets]

Hi.

I'm trying to figure out the state of this patch set.
Is there any chance for it to be accepted?

The first patch needs minor rebase. I could send a new version.

BTW, even without the first patch that raised some discussion
the last three patches are kind of straightforward and useful.

Best regards, Ilya Maximets.

On 27.11.2018 16:50, Ilya Maximets wrote:
> Version 2:
>     * First patch changed to just drop the memfd backend
>       if seals are not supported.
> 
> Ilya Maximets (4):
>   hostmem-memfd: disable for systems wihtout sealing support
>   memfd: always check for MFD_CLOEXEC
>   memfd: set up correct errno if not supported
>   memfd: improve error messages
> 
>  backends/hostmem-memfd.c | 18 ++++++++----------
>  tests/vhost-user-test.c  |  6 +++---
>  util/memfd.c             | 10 ++++++++--
>  3 files changed, 19 insertions(+), 15 deletions(-)
> 

Re: [Qemu-devel] [PATCH v2 0/4] memfd fixes.

[Marc-André Lureau]

Hi

On Mon, Mar 11, 2019 at 1:35 PM Ilya Maximets <i.maximets@samsung.com> wrote:
>
> Hi.
>
> I'm trying to figure out the state of this patch set.
> Is there any chance for it to be accepted?
>
> The first patch needs minor rebase. I could send a new version.

Please do,

I prefer the solution proposed in v2: do not register hostmem-memfd if
sealing isn't supported (keep sealing=true the default - it's one of
the main purpose of memfd imho).

Daniel, Eduardo: are you ok with this series for 4.0?

>
> BTW, even without the first patch that raised some discussion
> the last three patches are kind of straightforward and useful.
>
> Best regards, Ilya Maximets.
>
> On 27.11.2018 16:50, Ilya Maximets wrote:
> > Version 2:
> >     * First patch changed to just drop the memfd backend
> >       if seals are not supported.
> >
> > Ilya Maximets (4):
> >   hostmem-memfd: disable for systems wihtout sealing support
> >   memfd: always check for MFD_CLOEXEC
> >   memfd: set up correct errno if not supported
> >   memfd: improve error messages
> >
> >  backends/hostmem-memfd.c | 18 ++++++++----------
> >  tests/vhost-user-test.c  |  6 +++---
> >  util/memfd.c             | 10 ++++++++--
> >  3 files changed, 19 insertions(+), 15 deletions(-)
> >
>


-- 
Marc-André Lureau

Re: [Qemu-devel] [PATCH v2 0/4] memfd fixes.

[Daniel P. Berrangé]

On Mon, Mar 11, 2019 at 01:50:37PM +0100, Marc-André Lureau wrote:
> Hi
> 
> On Mon, Mar 11, 2019 at 1:35 PM Ilya Maximets <i.maximets@samsung.com> wrote:
> >
> > Hi.
> >
> > I'm trying to figure out the state of this patch set.
> > Is there any chance for it to be accepted?
> >
> > The first patch needs minor rebase. I could send a new version.
> 
> Please do,
> 
> I prefer the solution proposed in v2: do not register hostmem-memfd if
> sealing isn't supported (keep sealing=true the default - it's one of
> the main purpose of memfd imho).
> 
> Daniel, Eduardo: are you ok with this series for 4.0?

I prefer the more flexible approach, but I won't object to tieing memfd
to sealing support.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH v2 0/4] memfd fixes.

[Eduardo Habkost]

On Mon, Mar 11, 2019 at 12:56:14PM +0000, Daniel P. Berrangé wrote:
> On Mon, Mar 11, 2019 at 01:50:37PM +0100, Marc-André Lureau wrote:
> > Hi
> > 
> > On Mon, Mar 11, 2019 at 1:35 PM Ilya Maximets <i.maximets@samsung.com> wrote:
> > >
> > > Hi.
> > >
> > > I'm trying to figure out the state of this patch set.
> > > Is there any chance for it to be accepted?
> > >
> > > The first patch needs minor rebase. I could send a new version.
> > 
> > Please do,
> > 
> > I prefer the solution proposed in v2: do not register hostmem-memfd if
> > sealing isn't supported (keep sealing=true the default - it's one of
> > the main purpose of memfd imho).
> > 
> > Daniel, Eduardo: are you ok with this series for 4.0?
> 
> I prefer the more flexible approach, but I won't object to tieing memfd
> to sealing support.

Daniel, Marc-André: do you know if the libvirt QEMU capability
cache is invalidated when the host kernel version changes?

-- 
Eduardo

Re: [Qemu-devel] [PATCH v2 0/4] memfd fixes.

[Daniel P. Berrangé]

On Mon, Mar 11, 2019 at 11:12:29AM -0300, Eduardo Habkost wrote:
> On Mon, Mar 11, 2019 at 12:56:14PM +0000, Daniel P. Berrangé wrote:
> > On Mon, Mar 11, 2019 at 01:50:37PM +0100, Marc-André Lureau wrote:
> > > Hi
> > > 
> > > On Mon, Mar 11, 2019 at 1:35 PM Ilya Maximets <i.maximets@samsung.com> wrote:
> > > >
> > > > Hi.
> > > >
> > > > I'm trying to figure out the state of this patch set.
> > > > Is there any chance for it to be accepted?
> > > >
> > > > The first patch needs minor rebase. I could send a new version.
> > > 
> > > Please do,
> > > 
> > > I prefer the solution proposed in v2: do not register hostmem-memfd if
> > > sealing isn't supported (keep sealing=true the default - it's one of
> > > the main purpose of memfd imho).
> > > 
> > > Daniel, Eduardo: are you ok with this series for 4.0?
> > 
> > I prefer the more flexible approach, but I won't object to tieing memfd
> > to sealing support.
> 
> Daniel, Marc-André: do you know if the libvirt QEMU capability
> cache is invalidated when the host kernel version changes?

Yes kernl version is one of the many invalidation criteria:

https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_capabilities.c;h=c9700193fd0c404c16dd6f334b80255a4d1ba605;hb=HEAD#l4072

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|