the title says it is strongly related to ISM hardware.
Why being so specific?
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled
memory")
Signed-off-by: Matthew Rosato
Reviewed-by: Niklas Schnelle
Reviewed-by: Pierre Morel
Polite ping on this patch as the other 2 have now received maintainer
ACKs or reviews. I'm concerned about thi
register(q->matrix_mdev->kvm,
+q->saved_isc);
+ if (q->saved_pfn)
+ vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
+&q->saved_pfn, 1);
+
VIRTIO common code when the architecture restricts memory access
from the host.
The common code can then fail the probe for any device where
VIRTIO_F_ACCESS_PLATFORM is required, but not set.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
Reviewed-by: Halil Pasic
---
drivers/virtio
/s390/mm/init.c I wrongly removed in the last series.
Regards,
Pierre
Pierre Morel (2):
virtio: let arch advertise guest's memory access restrictions
s390: virtio: PV needs VIRTIO I/O device protection
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c
If protected virtualization is active on s390, VIRTIO has only retricted
access to the guest memory.
Define CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS and export
arch_has_restricted_virtio_memory_access to advertize VIRTIO if that's
the case.
Signed-off-by: Pierre Morel
Review
VIRTIO common code when the architecture restricts memory access
from the host.
The common code can then fail the probe for any device where
VIRTIO_F_ACCESS_PLATFORM is required, but not set.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
---
drivers/virtio/Kconfig| 6
igned-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
---
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index b29fcc66ec39..938246200d39 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kc
renamed the callback to arch_has_restricted_virtio_memory_access,
the config option to ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS,
and VIRTIO_F_IOMMU_PLATFORM to VIRTIO_F_ACCESS_PLATFORM.
Regards,
Pierre
Pierre Morel (2):
virtio: let arch advertise guest's memory access restrictions
s390: v
VIRTIO common code when the architecture restricts memory access
from the host.
The common code can then fail the probe for any device where
VIRTIO_F_IOMMU_PLATFORM is required, but not set.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
---
drivers/virtio/Kconfig| 6
renamed the callback to arch_has_restricted_virtio_memory_access,
and the config option to ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS.
Regards,
Pierre
Pierre Morel (2):
virtio: let arch advertise guest's memory access restrictions
s390: virtio: PV needs VIRTIO I/O device protection
arch
igned-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
---
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 9cfd8de907cb..c12422c26389 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kc
On 2020-08-21 13:59, Cornelia Huck wrote:
On Wed, 19 Aug 2020 18:23:17 +0200
Pierre Morel wrote:
An architecture may restrict host access to guest memory.
"e.g. IBM s390 Secure Execution or AMD SEV"
Just to make clearer what you are referring to?
yes, thanks
Provide a n
On 2020-08-21 14:05, Cornelia Huck wrote:
On Wed, 19 Aug 2020 18:23:18 +0200
Pierre Morel wrote:
If protected virtualization is active on s390, VIRTIO has retricted
s/retricted/only restricted/
access to the guest memory.
Define CONFIG_ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS and
d-off-by: Pierre Morel
---
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 9cfd8de907cb..c12422c26389 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -820,6 +820,7 @@
restrictions for
VIRTIO.
I renamed the callback to arch_has_restricted_virtio_memory_access,
and the config option to ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS.
Regards,
Pierre
Pierre Morel (2):
virtio: let arch advertise guest's memory access restrictions
s390: virtio: PV needs VIRTIO I/O d
restricts memory access
from the host.
Signed-off-by: Pierre Morel
---
drivers/virtio/Kconfig| 6 ++
drivers/virtio/virtio.c | 15 +++
include/linux/virtio_config.h | 9 +
3 files changed, 30 insertions(+)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio
function
would be short and sweet :)
yes, the smaller the better, thanks
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 2020-08-18 19:19, Cornelia Huck wrote:
On Tue, 18 Aug 2020 16:58:30 +0200
Pierre Morel 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
features.
Signed-off-by: Pierre Morel
---
drivers/virtio/Kconfig| 6 ++
drivers/virtio/virtio.c | 4
include/linux/virtio_config.h | 9 +
3 files changed, 19 insertions(+)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 5809e5f5b157..eef09e3c92f9
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 VIRTIO I/O device protection
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c
host error on access attempt.
Signed-off-by: Pierre Morel
---
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 9cfd8de907cb..d4a3ef4fa27b 100644
--- a/arch/s390/Kconfig
ORM? 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.
Yes thanks, I rework it in this direction.
--
Pierre Morel
IBM Lab Boeblingen
tempt.
Signed-off-by: Pierre Morel
---
drivers/s390/virtio/virtio_ccw.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c
index 5730572b52cd..cc8d8064c6c4 100644
--- a/drivers/s390/v
,
Pierre
Regards,
Pierre
Pierre Morel (1):
s390: virtio-ccw: PV needs VIRTIO I/O device protection
drivers/s390/virtio/virtio_ccw.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
--
2.25.1
On 2020-07-30 13:31, Pierre Morel wrote:
...snip...
What bothers me here is that arch code depends on virtio now.
It works even with a modular virtio when functions are inline,
but it seems fragile: e.g. it breaks virtio as an out of tree module,
since layout of struct virtio_device can
gentle ping.
On 2020-07-15 13:51, Michael S. Tsirkin wrote:
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
queue->ap_dev.device);
+ put_device(&queue->ap_dev.device);
return q;
}
this function changed a lot too, you should explain the goal in the
patch comment.
...snip...
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 2020-07-15 13:51, Michael S. Tsirkin wrote:
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
ff-by: Pierre Morel
Reviewed-by: Cornelia Huck
Acked-by: Halil Pasic
Acked-by: Christian Borntraeger
---
arch/s390/mm/init.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index 6dc7c3b60ef6..d39af6554d4f 100644
--- a
An architecture may need to validate the VIRTIO devices features
based on architecture specifics.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
Acked-by: Christian Borntraeger
Acked-by: Halil Pasic
---
drivers/virtio/virtio.c | 19 +++
include/linux
-by with these changes?
2) Rewording for warning messages
Regards,
Pierre
Pierre Morel (2):
virtio: let arch validate VIRTIO features
s390: virtio: PV needs VIRTIO I/O device protection
arch/s390/mm/init.c | 28
drivers/virtio/virtio.c | 19
On 2020-07-14 13:42, Christian Borntraeger wrote:
On 14.07.20 13:38, 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
-by with these changes?
2) Rewording for warning messages
Regards,
Pierre
Pierre Morel (2):
virtio: let arch validate VIRTIO features
s390: virtio: PV needs VIRTIO I/O device protection
arch/s390/mm/init.c | 28
drivers/virtio/virtio.c | 19
ff-by: Pierre Morel
Reviewed-by: Cornelia Huck
Acked-by: Halil Pasic
---
arch/s390/mm/init.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index 6dc7c3b60ef6..26efb663bac2 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s3
An architecture may need to validate the VIRTIO devices features
based on architecture specifics.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
Acked-by: Christian Borntraeger
Acked-by: Halil Pasic
---
drivers/virtio/virtio.c | 19 +++
include/linux
On 2020-07-09 16:47, Halil Pasic wrote:
On Thu, 9 Jul 2020 12:51:58 +0200
Pierre Morel 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
On 2020-07-09 11:55, Halil Pasic wrote:
On Thu, 9 Jul 2020 10:57:33 +0200
Cornelia Huck wrote:
On Thu, 9 Jul 2020 10:39:19 +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
On 2020-07-09 10:57, Cornelia Huck wrote:
On Thu, 9 Jul 2020 10:39:19 +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
On 2020-07-09 11:58, Halil Pasic wrote:
On Thu, 9 Jul 2020 10:39:18 +0200
Pierre Morel wrote:
An architecture may need to validate the VIRTIO devices features
based on architecture specifics.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
Acked-by: Christian Borntraeger
ff-by: Pierre Morel
---
arch/s390/mm/init.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index 6dc7c3b60ef6..b8e6f90117da 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -45,6 +45,7 @@
#include
#in
-by with these changes?
2) I suppressed the unnecessary verbosity of the architecture
specific patch
3) put back the arch specific code inside arch/s390/mm/init.c
after offline discussion with Christian.
Regards,
Pierre
Pierre Morel (2):
virtio: let arch validate VIRTIO features
s390
An architecture may need to validate the VIRTIO devices features
based on architecture specifics.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
Acked-by: Christian Borntraeger
---
drivers/virtio/virtio.c | 19 +++
include/linux/virtio_config.h | 1 +
2 files
On 2020-07-07 13:14, Michael S. Tsirkin wrote:
On Tue, Jul 07, 2020 at 11:46:33AM +0200, Cornelia Huck wrote:
On Tue, 7 Jul 2020 10:44:37 +0200
Pierre Morel wrote:
S390, protecting the guest memory against unauthorized host access
needs to enforce VIRTIO I/O device protection through the
On 2020-07-07 13:09, Christian Borntraeger wrote:
On 07.07.20 11:26, Cornelia Huck wrote:
On Tue, 7 Jul 2020 10:44:36 +0200
Pierre Morel wrote:
An architecture may need to validate the VIRTIO devices features
based on architecture specificities.
s/specifities/specifics/
yes
On 2020-07-07 13:12, Christian Borntraeger wrote:
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
On 2020-07-07 11:46, Cornelia Huck wrote:
On Tue, 7 Jul 2020 10:44:37 +0200
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.
Hm... what
On 2020-07-07 11:26, Cornelia Huck wrote:
On Tue, 7 Jul 2020 10:44:36 +0200
Pierre Morel wrote:
An architecture may need to validate the VIRTIO devices features
based on architecture specificities.
s/specifities/specifics/
OK
Signed-off-by: Pierre Morel
---
drivers/virtio
ed the patch into generic virtio and arch
specific code.
Regards,
Pierre
Pierre Morel (2):
virtio: let arch validate VIRTIO features
s390: virtio: PV needs VIRTIO I/O device protection
arch/s390/kernel/uv.c | 25 +
drivers/virtio/virtio.c
An architecture may need to validate the VIRTIO devices features
based on architecture specificities.
Signed-off-by: Pierre Morel
---
drivers/virtio/virtio.c | 19 +++
include/linux/virtio_config.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/virtio
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
---
arch/s390/kernel/uv.c | 25 +
1 file changed, 25 insertions
On 2020-07-06 16:33, Cornelia Huck wrote:
On Mon, 6 Jul 2020 15:37:37 +0200
Pierre Morel wrote:
On 2020-07-02 15:03, Pierre Morel wrote:
On 2020-06-29 18:05, Cornelia Huck wrote:
On Mon, 29 Jun 2020 11:57:14 -0400
"Michael S. Tsirkin" wrote:
On Wed, Jun 17, 2020 at
On 2020-07-02 15:03, Pierre Morel wrote:
On 2020-06-29 18:05, Cornelia Huck wrote:
On Mon, 29 Jun 2020 11:57:14 -0400
"Michael S. Tsirkin" wrote:
On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote:
An architecture protecting the guest memory against unauthorized h
On 2020-06-29 18:05, Cornelia Huck wrote:
On Mon, 29 Jun 2020 11:57:14 -0400
"Michael S. Tsirkin" wrote:
On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote:
An architecture protecting the guest memory against unauthorized host
access may want to enforce VIRTIO
On 2020-06-29 15:44, Cornelia Huck wrote:
On Mon, 29 Jun 2020 15:14:04 +0200
Pierre Morel wrote:
On 2020-06-19 11:20, Cornelia Huck wrote:
On Thu, 18 Jun 2020 00:29:56 +0200
Halil Pasic wrote:
On Wed, 17 Jun 2020 12:43:57 +0200
Pierre Morel wrote:
@@ -179,6 +194,13 @@ int
On 2020-06-29 18:09, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote:
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 g
On 2020-06-18 00:29, Halil Pasic wrote:
On Wed, 17 Jun 2020 12:43:57 +0200
Pierre Morel wrote:
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 chan
On 2020-06-19 11:20, Cornelia Huck wrote:
On Thu, 18 Jun 2020 00:29:56 +0200
Halil Pasic wrote:
On Wed, 17 Jun 2020 12:43:57 +0200
Pierre Morel wrote:
...
But since this can be rewritten any time, let's go with the option
people already agree with, instead of more discussion.
k with limited memory access" ?
But no issue with keeping the current message.
I think I prefer Conny's version, but no strong feelings here.
The reason why the device is not accepted without IOMMU_PLATFORM is arch
specific, I think it should be clearly stated.
If no strong oposition...
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 2020-06-29 17:57, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote:
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 g
On 2020-06-17 15:36, Tom Lendacky wrote:
On 6/17/20 5:43 AM, Pierre Morel wrote:
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 archite
On 2020-06-17 13:22, Heiko Carstens wrote:
On Wed, Jun 17, 2020 at 12:43:57PM +0200, Pierre Morel wrote:
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 g
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):
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.
Signed-off-by: Pierre
On 2020-06-16 14:17, Cornelia Huck wrote:
On Tue, 16 Jun 2020 13:57:26 +0200
Halil Pasic wrote:
On Tue, 16 Jun 2020 12:52:50 +0200
Pierre Morel wrote:
int virtio_finalize_features(struct virtio_device *dev)
{
int ret = dev->config->finalize_features(dev);
@@ -179,6 +
On 2020-06-16 14:20, Cornelia Huck wrote:
On Tue, 16 Jun 2020 12:52:50 +0200
Pierre Morel wrote:
On 2020-06-16 11:52, Halil Pasic wrote:
On Mon, 15 Jun 2020 14:39:24 +0200
Pierre Morel wrote:
@@ -162,6 +163,11 @@ bool force_dma_unencrypted(struct device *dev)
return
On 2020-06-16 11:52, Halil Pasic wrote:
On Mon, 15 Jun 2020 14:39:24 +0200
Pierre Morel wrote:
I find the subject (commit short) sub optimal. The 'arch' is already
accepting devices 'without IOMMU feature'. What you are introducing is
the ability to reject.
An archite
On 2020-06-16 08:55, Christian Borntraeger wrote:
On 15.06.20 14:39, Pierre Morel wrote:
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 t
On 2020-06-16 08:22, Jason Wang wrote:
On 2020/6/15 下午8:39, Pierre Morel wrote:
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 archite
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):
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.
Signed-off-by: Pierre
On 2020-06-15 05:01, Jason Wang wrote:
On 2020/6/12 下午7:38, Pierre Morel wrote:
On 2020-06-12 11:21, Pierre Morel wrote:
On 2020-06-11 05:10, Jason Wang wrote:
On 2020/6/10 下午9:11, Pierre Morel wrote:
Protected Virtualisation protects the memory of the guest and
do not allow a the
/2020/2/20/630
Regards,
Halil
OK, then back to the first idea.
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 2020-06-12 15:45, Mauricio Tavares wrote:
On Wed, Jun 10, 2020 at 12:32 PM Pierre Morel wrote:
Protected Virtualisation protects the memory of the guest and
do not allow a the host to access all of its memory.
Let's refuse a VIRTIO device which does not use IOMMU
protected a
On 2020-06-12 11:21, Pierre Morel wrote:
On 2020-06-11 05:10, Jason Wang wrote:
On 2020/6/10 下午9:11, Pierre Morel wrote:
Protected Virtualisation protects the memory of the guest and
do not allow a the host to access all of its memory.
Let's refuse a VIRTIO device which does no
On 2020-06-11 05:10, Jason Wang wrote:
On 2020/6/10 下午9:11, Pierre Morel wrote:
Protected Virtualisation protects the memory of the guest and
do not allow a the host to access all of its memory.
Let's refuse a VIRTIO device which does not use IOMMU
protected access.
Signed-off-by: P
On 2020-06-10 16:53, Cornelia Huck wrote:
On Wed, 10 Jun 2020 16:37:55 +0200
Pierre Morel wrote:
On 2020-06-10 15:24, Cornelia Huck wrote:
On Wed, 10 Jun 2020 15:11:51 +0200
Pierre Morel wrote:
Protected Virtualisation protects the memory of the guest and
do not allow a the host to
On 2020-06-10 15:24, Cornelia Huck wrote:
On Wed, 10 Jun 2020 15:11:51 +0200
Pierre Morel wrote:
Protected Virtualisation protects the memory of the guest and
do not allow a the host to access all of its memory.
Let's refuse a VIRTIO device which does not use IOMMU
protected a
Protected Virtualisation protects the memory of the guest and
do not allow a the host to access all of its memory.
Let's refuse a VIRTIO device which does not use IOMMU
protected access.
Signed-off-by: Pierre Morel
---
drivers/s390/virtio/virtio_ccw.c | 5 +
1 file changed, 5 inser
the one in the zdev struct.
Thanks,
Pierre
Reviewed-by: Pierre Morel
Fixes: 17cdec960cf77 (s390/pci: Recover handle in clp_set_pci_fn())
Signed-off-by: Petr Tesarik
---
arch/s390/pci/pci_clp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/s390/pci/pci_clp.c b
iommu to multifunction")
patch, not concerned by this merge problem, will be merged too at the end.
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 2020-04-28 00:24, Tony Krowiak wrote:
On 4/27/20 4:20 AM, Pierre Morel wrote:
On 2020-04-07 21:20, Tony Krowiak wrote:
Introduces a new driver callback to prevent a root user from unbinding
an AP queue from its device driver if the queue is in use. The intent of
this callback is to
rs/s390/crypto/vfio_ap_private.h | 12 +-
6 files changed, 1200 insertions(+), 496 deletions(-)
--
Pierre Morel
IBM Lab Boeblingen
antied that interrupt will be shut off after removing
the APQueue device
- The dynamic configuration series is not converging.
However Tony, the choice is your's, I won't be able to help
in a near future.
Pierre Morel (4):
s390: ap: kvm: add PQAP interception for AQIC
vfio: ap: reg
responsability of the driver to always initialize
the PQAP callback if it defines queues by initializing the CRYCB for
a guest.
If the callback has been setup we call it.
If not we setup an answer considering that no queue is available
for the guest when no callback has been setup.
Signed-off-by: Pierre Morel
virtio-balloon driver.
So the pinned page will never be freed. And even a broken guest does
so, that would not impact the host as the original page is still
in control by vfio.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
Reviewed-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c
process unregisters the GISA from the GIB,
and unpins the NIB address then we free the vfio_ap_queue
structure.
Signed-off-by: Pierre Morel
---
drivers/s390/crypto/vfio_ap_drv.c | 34 +++-
drivers/s390/crypto/vfio_ap_ops.c | 336 +-
drivers/s390/crypto
AP Queue Interruption Control (AQIC) facility gives
the guest the possibility to control interruption for
the Cryptographic Adjunct Processor queues.
Signed-off-by: Pierre Morel
Reviewed-by: Tony Krowiak
---
arch/s390/tools/gen_facilities.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
On 17/05/2019 20:04, Pierre Morel wrote:
On 17/05/2019 18:41, Alex Williamson wrote:
On Fri, 17 May 2019 18:16:50 +0200
Pierre Morel wrote:
We implement the capability interface for VFIO_IOMMU_GET_INFO.
When calling the ioctl, the user must specify
VFIO_IOMMU_INFO_CAPABILITIES to retrieve
On 16/05/2019 20:40, Alex Williamson wrote:
On Fri, 10 May 2019 10:22:35 +0200
Pierre Morel wrote:
We implement a capability intercafe for VFIO_IOMMU_GET_INFO and add the
first capability: VFIO_IOMMU_INFO_CAPABILITIES.
When calling the ioctl, the user must specify
On 08/05/2019 22:17, Tony Krowiak wrote:
On 5/2/19 1:34 PM, Pierre Morel wrote:
We register a AP PQAP instruction hook during the open
of the mediated device. And unregister it on release.
During the probe of the AP device, we allocate a vfio_ap_queue
structure to keep track of the information
On 09/05/2019 21:19, Parav Pandit wrote:
-Original Message-
From: Cornelia Huck
Sent: Thursday, May 9, 2019 4:06 AM
To: Parav Pandit
Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org;
kwankh...@nvidia.com; alex.william...@redhat.com; c...@nvidia.com;
Tony Krowiak ; Pierre Morel
it would have become a real issue.
We now increment/decrement the KVM reference counter inside open and
release.
Should be right after this.
Thanks for the cc,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
On 08/05/2019 17:48, Tony Krowiak wrote:
On 5/2/19 1:34 PM, Pierre Morel wrote:
We prepare the interception of the PQAP/AQIC instruction for
the case the AQIC facility is enabled in the guest.
First of all we do not want to change existing behavior when
intercepting AP instructions without the
On 06/05/2019 21:53, Tony Krowiak wrote:
On 5/6/19 2:49 AM, Pierre Morel wrote:
On 03/05/2019 23:14, Tony Krowiak wrote:
This patch introduces a shadow of the CRYCB being used by a guest. This
will enable to more effectively manage dynamic changes to the AP
resources installed on the host that
On 06/05/2019 21:37, Tony Krowiak wrote:
On 5/6/19 2:41 AM, Pierre Morel wrote:
On 03/05/2019 23:14, Tony Krowiak wrote:
Refactors the AP queue reset function to wait until the queue is empty
after the PQAP(ZAPQ) instruction is executed to zero out the queue as
required by the AP architecture
h is the only thing that can happen from out of the firmware
queue change requires configuration change and re-IPL.
Even still need testing, LGTM
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
atrix_dev->lock);
clear_bit_inv(domid, matrix_mdev->matrix.adm);
+
+ if (matrix_mdev->shadow_crycb) {
+ if (test_bit_inv(domid, matrix_mdev->shadow_crycb->adm)) {
+ clear_bit_inv(domid, matrix_mdev->shadow_crycb->adm);
+ vfio_ap_mdev_update_crycb(matrix_mdev);
+ }
+ }
mutex_unlock(&matrix_dev->lock);
return count;
beside the two NITs, look good to me.
Still need to test.
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
;t need to verify
+* that mdev's masks.
+*/
+ if ((mdev_apm == lstdev->matrix.apm) ||
+ (mdev_aqm == lstdev->matrix.aqm))
continue;
Is it possible that mdev_apm and mdev_aqm do not belong to the same
mediated device?
...snip...
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
ier: notifier block used for specifying callback function for
*handling the VFIO_GROUP_NOTIFY_SET_KVM event
* @kvm: the struct holding guest's state
@@ -79,6 +80,7 @@ struct ap_matrix {
struct ap_matrix_mdev {
struct list_head node;
struct ap_ma
1 - 100 of 532 matches
Mail list logo
