Displaying 20 results from an estimated 70 matches for "boeblingen".
2003 May 15
2
blibpath changes for AIX
...The ChangeLog contains
20030429
[...]
- (djm) Fix blibpath specification for AIX/gcc
[...]
which I suspect to be the cause for what I'm seeing. Could anybody
please comment?
TIA,
Markus
P.S.: Please copy me on your replies, as I'm not subscribed to the list.
--
Markus Alt
IBM Lab Boeblingen, Germany
altmark at de.ibm.com
2020 Jun 10
2
[PATCH] s390: protvirt: virtio: Refuse device without IOMMU
...}
+
+ if (is_prot_virt_guest() &&
+ !__virtio_test_bit(vdev, VIRTIO_F_IOMMU_PLATFORM))
+ return -EIO;
+
/* Give virtio_ring a chance to accept features. */
vring_transport_features(vdev);
Thanks,
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
2020 Jun 10
2
[PATCH] s390: protvirt: virtio: Refuse device without IOMMU
...}
+
+ if (is_prot_virt_guest() &&
+ !__virtio_test_bit(vdev, VIRTIO_F_IOMMU_PLATFORM))
+ return -EIO;
+
/* Give virtio_ring a chance to accept features. */
vring_transport_features(vdev);
Thanks,
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
2020 Jul 02
2
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
..._F_VERSION_1, not after?
>
> But it's only available with VERSION_1 anyway, isn't it? So it probably
> also needs to fail when this feature is needed if VERSION_1 has not been
> negotiated, I think.
>
Yes, clearly, I will add this.
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
2020 Jul 02
2
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
..._F_VERSION_1, not after?
>
> But it's only available with VERSION_1 anyway, isn't it? So it probably
> also needs to fail when this feature is needed if VERSION_1 has not been
> negotiated, I think.
>
Yes, clearly, I will add this.
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
2020 Jul 07
3
[PATCH v4 1/2] virtio: let arch validate VIRTIO features
On Tue, 7 Jul 2020 10:44:36 +0200
Pierre Morel <pmorel at linux.ibm.com> wrote:
> An architecture may need to validate the VIRTIO devices features
> based on architecture specificities.
s/specifities/specifics/
>
> Signed-off-by: Pierre Morel <pmorel at linux.ibm.com>
> ---
> drivers/virtio/virtio.c | 19 +++++++++++++++++++
>
2020 Jul 07
3
[PATCH v4 1/2] virtio: let arch validate VIRTIO features
On Tue, 7 Jul 2020 10:44:36 +0200
Pierre Morel <pmorel at linux.ibm.com> wrote:
> An architecture may need to validate the VIRTIO devices features
> based on architecture specificities.
s/specifities/specifics/
>
> Signed-off-by: Pierre Morel <pmorel at linux.ibm.com>
> ---
> drivers/virtio/virtio.c | 19 +++++++++++++++++++
>
2020 Jun 29
2
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
...ess" ?
>
> But no issue with keeping the current message.
>
If it is OK, I would like to specify that the arch is responsible to
accept or not the device.
The reason why the device is not accepted without IOMMU_PLATFORM is arch
specific.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
2020 Jun 29
2
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
...ess" ?
>
> But no issue with keeping the current message.
>
If it is OK, I would like to specify that the arch is responsible to
accept or not the device.
The reason why the device is not accepted without IOMMU_PLATFORM is arch
specific.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
2020 Jul 15
5
[PATCH v7 2/2] s390: virtio: PV needs VIRTIO I/O device protection
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
2020 Jul 15
5
[PATCH v7 2/2] s390: virtio: PV needs VIRTIO I/O device protection
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
2020 Jun 15
3
[PATCH] s390: protvirt: virtio: Refuse device without IOMMU
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 host to access all of its memory.
>>>>
2020 Jun 15
3
[PATCH] s390: protvirt: virtio: Refuse device without IOMMU
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 host to access all of its memory.
>>>>
2020 Jun 12
2
[PATCH] s390: protvirt: virtio: Refuse device without IOMMU
...ble that the architecture
would overwrite if needed but I find the weak function solution more
flexible.
With a function, we also have the possibility to provide the device as
argument and take actions depending it, this may answer Halil's concern.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
2020 Jun 12
2
[PATCH] s390: protvirt: virtio: Refuse device without IOMMU
...ble that the architecture
would overwrite if needed but I find the weak function solution more
flexible.
With a function, we also have the possibility to provide the device as
argument and take actions depending it, this may answer Halil's concern.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
2020 Jun 29
3
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
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 give a chance to the architecture to accept or not devices
> without VIRTIO_F_IOMMU_PLATFORM.
>
> Signed-off-by: Pierre
2020 Jun 29
3
[PATCH v3 1/1] s390: virtio: let arch accept devices without IOMMU feature
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 give a chance to the architecture to accept or not devices
> without VIRTIO_F_IOMMU_PLATFORM.
>
> Signed-off-by: Pierre
2020 Jun 10
5
[PATCH] s390: protvirt: virtio: Refuse device without IOMMU
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 <pmorel at linux.ibm.com>
---
drivers/s390/virtio/virtio_ccw.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/s390/virtio/virtio_ccw.c
2020 Jun 10
5
[PATCH] s390: protvirt: virtio: Refuse device without IOMMU
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 <pmorel at linux.ibm.com>
---
drivers/s390/virtio/virtio_ccw.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/s390/virtio/virtio_ccw.c
2020 Jul 09
4
[PATCH v5 2/2] s390: virtio: PV needs VIRTIO I/O device protection
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