Displaying 10 results from an estimated 10 matches for "arch_has_restricted_memory_access".
2020 Aug 18
4
[PATCH v8 0/2] s390: virtio: let arch validate VIRTIO features
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 entry.
Regards,
Pierre
Pierre Morel (2):
virtio: let arch validate VIRTIO features
s390: virtio: PV needs V...
2020 Aug 18
2
[PATCH v8 1/2] virtio: let arch validate VIRTIO features
On Tue, 18 Aug 2020 16:58:30 +0200
Pierre Morel <pmorel at linux.ibm.com> wrote:
> An architecture may need to validate the VIRTIO devices features
> based on architecture specifics.
>
> Provide a new Kconfig entry, CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS,
> the architecture can select when it provides a callback named
> arch_has_restricted_memory_access to validate the virtio device
> features.
>
> Signed-off-by: Pierre Morel <pmorel at linux.ibm.com>
> ---
> drivers/virtio/Kconfig | 6 ++++++
> drivers/virtio...
2020 Aug 18
2
[PATCH v8 1/2] virtio: let arch validate VIRTIO features
On Tue, 18 Aug 2020 16:58:30 +0200
Pierre Morel <pmorel at linux.ibm.com> wrote:
> An architecture may need to validate the VIRTIO devices features
> based on architecture specifics.
>
> Provide a new Kconfig entry, CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS,
> the architecture can select when it provides a callback named
> arch_has_restricted_memory_access to validate the virtio device
> features.
>
> Signed-off-by: Pierre Morel <pmorel at linux.ibm.com>
> ---
> drivers/virtio/Kconfig | 6 ++++++
> drivers/virtio...
2020 Aug 18
1
[PATCH v8 2/2] s390: virtio: PV needs VIRTIO I/O device protection
On Tue, 18 Aug 2020 16:58:31 +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.
> Define CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS and export
> arch_has_restricted_memory_access to fail probe if that's
> not the case, preventing a host error on access attempt.
>
> Signed-off-by: Pierre Morel <pmorel at linux.ibm.com>
> ---
> arch/s390/Kconfig | 1 +
> arch/s390/mm/init.c | 30 +++++++++++++++...
2020 Aug 18
0
[PATCH v8 2/2] s390: virtio: PV needs VIRTIO I/O device protection
If protected virtualization is active on s390, the virtio queues are
not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been
negotiated.
Define CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS and export
arch_has_restricted_memory_access to fail probe if that's
not the case, preventing a host error on access attempt.
Signed-off-by: Pierre Morel <pmorel at linux.ibm.com>
---
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 3...
2020 Aug 18
0
[PATCH v8 1/2] virtio: let arch validate VIRTIO features
An architecture may need to validate the VIRTIO devices features
based on architecture specifics.
Provide a new Kconfig entry, CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS,
the architecture can select when it provides a callback named
arch_has_restricted_memory_access to validate the virtio device
features.
Signed-off-by: Pierre Morel <pmorel at linux.ibm.com>
---
drivers/virtio/Kconfig | 6 ++++++
drivers/virtio/virtio.c | 4 ++++
include/linux/...
2020 Aug 19
0
[PATCH v8 1/2] virtio: let arch validate VIRTIO features
On 2020-08-18 19:19, Cornelia Huck wrote:
> On Tue, 18 Aug 2020 16:58:30 +0200
> Pierre Morel <pmorel at linux.ibm.com> wrote:
>
...
>> +config ARCH_HAS_RESTRICTED_MEMORY_ACCESS
>> + bool
>> + help
>> + This option is selected by any architecture enforcing
>> + VIRTIO_F_IOMMU_PLATFORM
>
> This option is only for a very specific case of "restricted memory
> access", namely the kind that requires IOMMU_PLATFORM for virtio
>...
2020 Aug 06
3
[PATCH v1 0/1] s390: virtio-ccw: PV needs VIRTIO I/O device protection
Hi all,
In another series I proposed to add an architecture specific
callback to fail feature negociation on architecture need.
In VIRTIO, we already have an entry to reject the features on the
transport basis.
Transport is not architecture so I send a separate series in which
we fail the feature negociation inside virtio_ccw_finalize_features,
the virtio_config_ops.finalize_features for S390
2020 Aug 06
3
[PATCH v1 0/1] s390: virtio-ccw: PV needs VIRTIO I/O device protection
Hi all,
In another series I proposed to add an architecture specific
callback to fail feature negociation on architecture need.
In VIRTIO, we already have an entry to reject the features on the
transport basis.
Transport is not architecture so I send a separate series in which
we fail the feature negociation inside virtio_ccw_finalize_features,
the virtio_config_ops.finalize_features for S390
2020 Aug 06
0
[PATCH v1 0/1] s390: virtio-ccw: PV needs VIRTIO I/O device protection
...rchitecture solution already
(especially keeping in mind that ccw is the only transport that is
really architecture-specific).
I know that we've gone through a few rounds already, and I'm not sure
whether we've been there already, but:
Could virtio_finalize_features() call an optional
arch_has_restricted_memory_access() function and do the enforcing of
IOMMU_PLATFORM? That would catch all transports, and things should work
once an architecture opts in. That direction also shouldn't be a
problem if virtio is a module.
>
> Regards,
> Pierre
>
> Regards,
> Pierre
>
> Pierre Morel (1)...