similar to: [PATCH v4 0/2] s390: virtio: let arch validate VIRTIO features

On Tue, 7 Jul 2020 10:44:37 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > S390, protecting the guest memory against unauthorized host access > needs to enforce VIRTIO I/O device protection through the use of > VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM. Hm... what about: "If protected virtualization is active on s390, the virtio queues are not accessible to the

On Tue, 7 Jul 2020 10:44:37 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > S390, protecting the guest memory against unauthorized host access > needs to enforce VIRTIO I/O device protection through the use of > VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM. Hm... what about: "If protected virtualization is active on s390, the virtio queues are not accessible to the

On 07.07.20 10:44, Pierre Morel wrote: > S390, protecting the guest memory against unauthorized host access > needs to enforce VIRTIO I/O device protection through the use of > VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM. > > Signed-off-by: Pierre Morel <pmorel at linux.ibm.com> > --- > arch/s390/kernel/uv.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25

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):

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

On Thu, 9 Jul 2020 10:39:19 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > If protected virtualization is active on s390, the virtio queues are > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been > negotiated. Use the new arch_validate_virtio_features() interface to > fail probe if that's not the case, preventing a host error on access > attempt

On Thu, 9 Jul 2020 10:39:19 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > If protected virtualization is active on s390, the virtio queues are > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been > negotiated. Use the new arch_validate_virtio_features() interface to > fail probe if that's not the case, preventing a host error on access > attempt

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 Wed, Jul 15, 2020 at 06:16:59PM +0800, Jason Wang wrote: > > On 2020/7/15 ??5:50, Michael S. Tsirkin wrote: > > On Wed, Jul 15, 2020 at 10:31:09AM +0200, Pierre Morel wrote: > > > If protected virtualization is active on s390, the virtio queues are > > > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been > > > negotiated. Use the new

On Wed, Jul 15, 2020 at 06:16:59PM +0800, Jason Wang wrote: > > On 2020/7/15 ??5:50, Michael S. Tsirkin wrote: > > On Wed, Jul 15, 2020 at 10:31:09AM +0200, Pierre Morel wrote: > > > If protected virtualization is active on s390, the virtio queues are > > > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been > > > negotiated. Use the new

On Wed, Jul 15, 2020 at 10:31:09AM +0200, Pierre Morel wrote: > If protected virtualization is active on s390, the virtio queues are > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been > negotiated. Use the new arch_validate_virtio_features() interface to > fail probe if that's not the case, preventing a host error on access > attempt. > > Signed-off-by:

On Wed, Jul 15, 2020 at 10:31:09AM +0200, Pierre Morel wrote: > If protected virtualization is active on s390, the virtio queues are > not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been > negotiated. Use the new arch_validate_virtio_features() interface to > fail probe if that's not the case, preventing a host error on access > attempt. > > Signed-off-by:

On 2020-07-07 11:46, Cornelia Huck wrote: > On Tue, 7 Jul 2020 10:44:37 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > >> S390, protecting the guest memory against unauthorized host access >> needs to enforce VIRTIO I/O device protection through the use of >> VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM. > > Hm... what about: > > "If

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

On Tue, Jul 07, 2020 at 11:46:33AM +0200, Cornelia Huck wrote: > On Tue, 7 Jul 2020 10:44:37 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > > > S390, protecting the guest memory against unauthorized host access > > needs to enforce VIRTIO I/O device protection through the use of > > VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM. > > Hm... what

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

An architecture protecting the guest memory against unauthorized host access may want to enforce VIRTIO I/O device protection through the use of VIRTIO_F_IOMMU_PLATFORM. Let's give a chance to the architecture to accept or not devices without VIRTIO_F_IOMMU_PLATFORM. Pierre Morel (1): s390: virtio: let arch accept devices without IOMMU feature arch/s390/mm/init.c | 6 ++++++

An architecture protecting the guest memory against unauthorized host access may want to enforce VIRTIO I/O device protection through the use of VIRTIO_F_IOMMU_PLATFORM. Let's give a chance to the architecture to accept or not devices without VIRTIO_F_IOMMU_PLATFORM. Pierre Morel (1): s390: virtio: let arch accept devices without IOMMU feature arch/s390/mm/init.c | 6 ++++++

On Thu, 9 Jul 2020 12:51:58 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > >> +int arch_validate_virtio_features(struct virtio_device *dev) > >> +{ > >> + if (!is_prot_virt_guest()) > >> + return 0; > >> + > >> + if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1)) { > >> + dev_warn(&dev->dev, "device must

On Thu, 9 Jul 2020 12:51:58 +0200 Pierre Morel <pmorel at linux.ibm.com> wrote: > >> +int arch_validate_virtio_features(struct virtio_device *dev) > >> +{ > >> + if (!is_prot_virt_guest()) > >> + return 0; > >> + > >> + if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1)) { > >> + dev_warn(&dev->dev, "device must