gt;path_notoper_mask = 0;
@@ -626,7 +626,7 @@ struct stlck_data {
static void stlck_build_cp(struct ccw_device *cdev, void *buf1, void *buf2)
{
struct ccw_request *req = &cdev->private->req;
- struct ccw1 *cp = cdev->private->iccws;
+ struct ccw1 *cp = cdev->private->dma_area->iccws;
cp[0].cmd_code = CCW_CMD_STLCK;
cp[0].cda = (u32) (addr_t) buf1;
diff --git a/drivers/s390/cio/device_status.c b/drivers/s390/cio/device_status.c
index 7d5c7892b2c4..a9aabde604f4 100644
--- a/drivers/s390/cio/device_status.c
+++ b/drivers/s390/cio/device_status.c
@@ -79,15 +79,15 @@ ccw_device_accumulate_ecw(struct ccw_device *cdev, struct
irb *irb)
* are condition that have to be met for the extended control
* bit to have meaning. Sick.
*/
- cdev->private->irb.scsw.cmd.ectl = 0;
+ cdev->private->dma_area->irb.scsw.cmd.ectl = 0;
if ((irb->scsw.cmd.stctl & SCSW_STCTL_ALERT_STATUS) &&
!(irb->scsw.cmd.stctl & SCSW_STCTL_INTER_STATUS))
- cdev->private->irb.scsw.cmd.ectl = irb->scsw.cmd.ectl;
+ cdev->private->dma_area->irb.scsw.cmd.ectl = irb->scsw.cmd.ectl;
/* Check if extended control word is valid. */
- if (!cdev->private->irb.scsw.cmd.ectl)
+ if (!cdev->private->dma_area->irb.scsw.cmd.ectl)
return;
/* Copy concurrent sense / model dependent information. */
- memcpy (&cdev->private->irb.ecw, irb->ecw, sizeof (irb->ecw));
+ memcpy (&cdev->private->dma_area->irb.ecw, irb->ecw, sizeof (irb->ecw));
NIT, may be you should take the opportunity to remove the blanc before
the parenthesis.
NIT again, Some lines over 80 character too.
just a first check, I will go deeper later.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
_bit(0, &vcdev->indicators2);
+ clear_bit(0, indicators2(vcdev));
}
}
Here again just a fast check.
I will go in the functional later.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
FLAG_SLI;
@@ -1500,6 +1509,7 @@ static int __init virtio_ccw_init(void)
{
/* parse no_auto string before we do anything further */
no_auto_parse();
+ summary_indicators = cio_dma_zalloc(MAX_AIRQ_AREAS);
return ccw_driver_register(&virtio_ccw_dri
On 08/05/2019 16:46, Pierre Morel wrote:
On 26/04/2019 20:32, Halil Pasic wrote:
Before virtio-ccw could get away with not using DMA API for the pieces of
memory it does ccw I/O with. With protected virtualization this has to
change, since the hypervisor needs to read and sometimes also write
| GFP_KERNEL);
+ indicatorp = __vc_dma_alloc(&vcdev->vdev,
+ sizeof(indicators(vcdev)));
should be sizeof(long) ?
This is a recurrent error, but it is not an issue because the size of
the indicators is unsigned long as the size of the poin
On 09/05/2019 20:26, Halil Pasic wrote:
On Thu, 9 May 2019 14:01:01 +0200
Pierre Morel wrote:
On 08/05/2019 16:31, Pierre Morel wrote:
On 26/04/2019 20:32, Halil Pasic wrote:
This will come in handy soon when we pull out the indicators from
virtio_ccw_device to a memory area that is shared
On 08/05/2019 16:31, Pierre Morel wrote:
On 26/04/2019 20:32, Halil Pasic wrote:
This will come in handy soon when we pull out the indicators from
virtio_ccw_device to a memory area that is shared with the hypervisor
(in particular for protected virtualization guests).
Signed-off-by: Halil
On 10/05/2019 13:54, Halil Pasic wrote:
On Fri, 10 May 2019 09:43:08 +0200
Pierre Morel wrote:
On 09/05/2019 20:26, Halil Pasic wrote:
On Thu, 9 May 2019 14:01:01 +0200
Pierre Morel wrote:
On 08/05/2019 16:31, Pierre Morel wrote:
On 26/04/2019 20:32, Halil Pasic wrote:
This will come in
On 13/05/2019 12:15, Cornelia Huck wrote:
On Fri, 10 May 2019 17:36:05 +0200
Pierre Morel wrote:
On 10/05/2019 13:54, Halil Pasic wrote:
On Fri, 10 May 2019 09:43:08 +0200
Pierre Morel wrote:
On 09/05/2019 20:26, Halil Pasic wrote:
On Thu, 9 May 2019 14:01:01 +0200
Pierre Morel wrote
device
to send a reset to the host virtio device.
Signed-off-by: Pierre Morel
Reviewed-by: Cornelia Huck
---
net/9p/trans_virtio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 9dd49ca..6e70ddb 100644
--- a/net/9p/trans_virtio.c
+++ b/
ff-by: Pierre Morel
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 143d8a9..c042ffd 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2734,9 +2734,9 @@ module
cks in virtio_net_driver_exit.
This patch solves the problem by first unregistering the virtio_net_driver
before unregistering the hotplug state machine callbacks.
Best regards,
Pierre Morel
Pierre Morel (1):
net/virtio-net: reverse unregistering on exit
drivers/net/virtio_net.c | 2 +-
On 22/08/2017 20:13, Michael S. Tsirkin wrote:
On Tue, Aug 22, 2017 at 04:59:52PM +0200, Pierre Morel wrote:
unregister_virtio_driver should be done before the unregistering of
the hotplug state machine callbacks, otherwise the state machine still
holds some instance states at that time.
Let&#
On 22/08/2017 20:17, Michael S. Tsirkin wrote:
On Tue, Aug 22, 2017 at 04:59:51PM +0200, Pierre Morel wrote:
Hi,
I got a problem with virtio-net in a QEMU guest.
When virtio-net is used as a module in a guest and the network is
activated, removing the virtio-net modules produces a kernel
need your opinion: Is it right?
This patch also lead to another question:
do we care if a device provided by the hypervisor is buggy?
Signed-off-by: Pierre Morel
---
drivers/virtio/virtio.c| 4
drivers/virtio/virtio_pci_modern.c | 11 ++-
2 files changed, 14 insertions
On 24/08/2017 13:07, Cornelia Huck wrote:
On Wed, 23 Aug 2017 18:33:02 +0200
Pierre Morel wrote:
Reseting a device can sometime fail, even a virtual device.
If the device is not reseted after a while the driver should
abandon the retries.
This is the change proposed for the modern virtio_pci
On 24/08/2017 16:12, Michael S. Tsirkin wrote:
On Thu, Aug 24, 2017 at 02:16:11PM +0200, Pierre Morel wrote:
On 24/08/2017 13:07, Cornelia Huck wrote:
On Wed, 23 Aug 2017 18:33:02 +0200
Pierre Morel wrote:
Reseting a device can sometime fail, even a virtual device.
If the device is not
On 24/08/2017 16:19, Michael S. Tsirkin wrote:
On Wed, Aug 23, 2017 at 06:33:02PM +0200, Pierre Morel wrote:
Reseting a device can sometime fail, even a virtual device.
If the device is not reseted after a while the driver should
abandon the retries.
This is the change proposed for the modern
On 24/08/2017 23:23, Michael S. Tsirkin wrote:
On Thu, Aug 24, 2017 at 07:42:07PM +0200, Pierre Morel wrote:
On 24/08/2017 16:19, Michael S. Tsirkin wrote:
On Wed, Aug 23, 2017 at 06:33:02PM +0200, Pierre Morel wrote:
Reseting a device can sometime fail, even a virtual device.
If the device
On 25/08/2017 10:26, Cornelia Huck wrote:
On Fri, 25 Aug 2017 00:16:05 +0300
"Michael S. Tsirkin" wrote:
On Thu, Aug 24, 2017 at 07:07:42PM +0200, Pierre Morel wrote:
- we'll have to spread these tests all over the place.
I counted 19 places where to check if the reset we
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
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
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-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-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-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
/2020/2/20/630
Regards,
Halil
OK, then back to the first idea.
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
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
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 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
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 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 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 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 +
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
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):
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
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-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 oposi
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-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-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-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-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-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 12:43:
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
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
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
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
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 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 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: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
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
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
-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
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
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: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 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
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
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
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
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
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
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
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
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
,
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
___
Virtualization mailing
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
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
___
Virtualizati
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
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
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
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
function
would be short and sweet :)
yes, the smaller the better, thanks
Pierre
--
Pierre Morel
IBM Lab Boeblingen
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
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
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
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
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
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
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_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
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
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
95 matches
Mail list logo
