On 03/07/2018 11:22 AM, Pierre Morel wrote:
> On 06/03/2018 18:10, David Hildenbrand wrote:
>>> If L2 forward devices to L3 through SIE ECA.28 but no bit is set is in
>>> the CRYCB of L2,
>>> L3 will not see any device.
>> Exactly and this is the problem: How should L2 know that these devices
>>
On 06/03/2018 18:10, David Hildenbrand wrote:
If L2 forward devices to L3 through SIE ECA.28 but no bit is set is in
the CRYCB of L2,
L3 will not see any device.
Exactly and this is the problem: How should L2 know that these devices
are special and cannot be forwarded.
This is what we call
> If L2 forward devices to L3 through SIE ECA.28 but no bit is set is in
> the CRYCB of L2,
> L3 will not see any device.
Exactly and this is the problem: How should L2 know that these devices
are special and cannot be forwarded.
>
>>
>> This is what we call the nightmare of nested
On 06/03/2018 11:01, David Hildenbrand wrote:
On 27.02.2018 16:44, Tony Krowiak wrote:
This patch series is the QEMU counterpart to the KVM/kernel support for
guest dedicated crypto adapters. The KVM/kernel model is built on the
VFIO mediated device framework and provides the infrastructure for
On 27.02.2018 16:44, Tony Krowiak wrote:
> This patch series is the QEMU counterpart to the KVM/kernel support for
> guest dedicated crypto adapters. The KVM/kernel model is built on the
> VFIO mediated device framework and provides the infrastructure for
> granting exclusive guest access to
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1519746259-27710-1-git-send-email-akrow...@linux.vnet.ibm.com
Subject: [Qemu-devel] [PATCH v2 0/5] s390x: vfio-ap: guest dedicated crypto
adapters
=== TEST SCRIPT BEGIN
This patch series is the QEMU counterpart to the KVM/kernel support for
guest dedicated crypto adapters. The KVM/kernel model is built on the
VFIO mediated device framework and provides the infrastructure for
granting exclusive guest access to crypto devices installed on the linux
host. This