search for: conny

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. in this respin: The tests are back to virtio_finalize_features. No more argument for the architecture callback which only reports if the architecture needs guest memory access restrictions for VIRTIO. I renamed the callback to arch_has_restricted_virtio_memory_access, and the config

On Thu, 13 Jun 2019 11:11:13 +0200 Michael Mueller <mimu at linux.ibm.com> wrote: > Halil, > > I just ran my toleration tests successfully on current HW for > this series. > > Michael Thanks Michael! May I add a Tested-by: Michael Mueller <mimu at linux.ibm.com> for each patch? > > On 12.06.19 13:12, Halil Pasic wrote: > > Enhanced virtualization

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. in this respin: I use the original idea from Connie for an optional arch_has_restricted_memory_access. I renamed the callback accordingly, added the definition of ARCH_HAS_RESTRICTED_MEMORY_ACCESS inside the VIRTIO Kconfig and the selection in the PROTECTED_VIRTUALIZATION_GUEST config

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. I changed VIRTIO_F_IOMMU_PLATFORM to VIRTIO_F_ACCESS_PLATFORM I forgot in drivers/virtio/Kconfig, and put back the inclusion of virtio_config.h for the definition of the callback in arch/s390/mm/init.c I wrongly removed in the last series. Regards, Pierre Pierre Morel (2): virtio: let

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. I changed VIRTIO_F_IOMMU_PLATFORM to VIRTIO_F_ACCESS_PLATFORM I forgot in drivers/virtio/Kconfig, and put back the inclusion of virtio_config.h for the definition of the callback in arch/s390/mm/init.c I wrongly removed in the last series. Regards, Pierre Pierre Morel (2): virtio: let

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. in this respin: 1) I kept removed the ack from Jason as I reworked the patch @Jason, the nature and goal of the patch did not really changed please can I get back your acked-by with these changes? 2) Rewording for warning messages Regards, Pierre Pierre Morel (2):

Someone told me that if you have a CentOS or Fedora server, you can pay a Red Hat yearly fee and get them to support it (because the environments are so similar). Can anyone here substantiate this claim? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20091211/03c9856b/attachment.html>

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. The tests are back to virtio_finalize_features. No more argument for the architecture callback which only reports if the architecture needs guest memory access restrictions for VIRTIO. I renamed the callback to arch_has_restricted_virtio_memory_access, and the config option to

Halil, I just ran my toleration tests successfully on current HW for this series. Michael On 12.06.19 13:12, Halil Pasic wrote: > Enhanced virtualization protection technology may require the use of > bounce buffers for I/O. While support for this was built into the virtio > core, virtio-ccw wasn't changed accordingly. > > Some background on technology (not part of this

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. in this respin: 1) I kept removed the ack from Jason as I reworked the patch @Jason, the nature and goal of the patch did not really changed please can I get back your acked-by with these changes? 2) Rewording for warning messages Regards, Pierre Pierre Morel (2):

On 09/25/2017 07:54 PM, Halil Pasic wrote: > > > On 09/25/2017 04:45 PM, Thomas Huth wrote: >> There is no recent user space application available anymore which still >> supports this old virtio transport, so let's disable this by default. >> >> Signed-off-by: Thomas Huth <thuth at redhat.com> > > I don't have any objections, but there may be

On 09/25/2017 07:54 PM, Halil Pasic wrote: > > > On 09/25/2017 04:45 PM, Thomas Huth wrote: >> There is no recent user space application available anymore which still >> supports this old virtio transport, so let's disable this by default. >> >> Signed-off-by: Thomas Huth <thuth at redhat.com> > > I don't have any objections, but there may be

...gt;> FWIW as the original author of that transport >> Acked-by: Christian Borntraeger <borntraeger at de.ibm.com> >> >> I can pick this up for Martins/Heikos tree if you want. > > When will this code be removed? > > When the config option was initially added Conny said it should survive > "probably two kernel releases or so, depending on feedback". > It was merged for v4.8. Now we are five kernel releases later... Lets wait for one release and then get rid of it?

...gt;> FWIW as the original author of that transport >> Acked-by: Christian Borntraeger <borntraeger at de.ibm.com> >> >> I can pick this up for Martins/Heikos tree if you want. > > When will this code be removed? > > When the config option was initially added Conny said it should survive > "probably two kernel releases or so, depending on feedback". > It was merged for v4.8. Now we are five kernel releases later... Lets wait for one release and then get rid of it?

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. The tests are back to virtio_finalize_features. No more argument for the architecture callback which only reports if the architecture needs guest memory access restrictions for VIRTIO. I renamed the callback to arch_has_restricted_virtio_memory_access, the config option to

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. The tests are back to virtio_finalize_features. No more argument for the architecture callback which only reports if the architecture needs guest memory access restrictions for VIRTIO. I renamed the callback to arch_has_restricted_virtio_memory_access, the config option to

Hi all, The goal of the series is to give a chance to the architecture to validate VIRTIO device features. in this respin: 1) I kept removed the ack from Jason as I reworked the patch @Jason, the nature and goal of the patch did not really changed please can I get back your acked-by with these changes? 2) I suppressed the unnecessary verbosity of the architecture specific

Hello list, my name is Steven and of course: I got a problem... we are using dovecot 0.99 because it?s the actual stable version for RedHat 4 Enterprise. I am trying to authenticate using "PLAIN" but I don?t know how. that?s what I am doing: telnet conny.MYDOMAIN.de 143 Trying IP.AD.RE.SS... Connected to conny.MYDOMAIN.de. Escape character is '^]'. * OK dovecot ready. a1 authenticate plain + a1 NO Authentication failed. what do I have to send after receiving the "+"-symbol? dovecot is waiting for something base64-encoded and I...

FYI, I see the following build error with this patch... MRJ ---- new warnings/errors for xen ---- keyhandler.c: In function `__dump_execstate'': keyhandler.c:96: warning: asm operand 1 probably doesn''t match constraints gmake[5]: *** [keyhandler.o] Error 1 gmake[4]: *** [/tank/ws/xvm-3.4.3/xen.hg/xen/common/built_in.o] Error 2 gmake[3]: *** [/tank/ws/xvm-3.4.3/xen.hg/xen/xen]

Hi all, I changed the patch subject to reflect the content, becoming more general. 1) I removed the ack from Christian and Jason even far as I understand they gave it for the functionality more than for the implementation. @Jason, @Christian, please can I get back your acked-by with these changes? 2) previous patch had another name: [PATCH v3 0/1] s390: virtio: let arch choose to