a PONG_READ CCW command.
- defines a Control Unit property.
Pierre Morel (1):
s390x: css: pong, channel subsystem test device
default-configs/s390x-softmmu.mak | 1 +
hw/s390x/Kconfig | 3 +
hw/s390x/Makefile.objs| 1 +
hw/s390x/ccw-pong.c | 140
On 2020-02-18 13:44, Cornelia Huck wrote:
On Thu, 13 Feb 2020 18:54:37 +
Peter Maydell wrote:
On Thu, 13 Feb 2020 at 18:38, Pierre Morel
wrote:> However it may be because I do not use the right tools.
Did not find which one I am suppose to use.
Currently using:
rst2latex vfio-ap.
6, 7 |
+--+++
However it may be because I do not use the right tools.
Did not find which one I am suppose to use.
Currently using:
rst2latex vfio-ap.rst > vfio-ap.tex && pdflatex vfio-ap.tex
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 2019-11-28 13:28, Janosch Frank wrote:
On 11/28/19 11:13 AM, Pierre Morel wrote:
A new proposition:
I think it would be wise to fork directly from handle_instruction
instead to accept per default all instructions with with secure
instruction interception code.
Just in case future firmware
On 2019-11-28 13:10, Thomas Huth wrote:
On 28/11/2019 11.13, Pierre Morel wrote:
The SCLP protection handle some of the exceptions due to
mis-constructions of the SCLP Control Block (SCCB) by the guest and
provides notifications to the host when something gets wrong.
We currently do not handle
.
Currently only the kvm-unit-test css test uses the PONG device.
Signed-off-by: Pierre Morel
---
default-configs/s390x-softmmu.mak | 1 +
hw/s390x/Kconfig | 3 +
hw/s390x/Makefile.objs| 1 +
hw/s390x/ccw-pong.c | 134
a PONG_READ CCW command.
- defines a Control Unit property.
Pierre Morel (1):
s390x: css: pong, channel subsystem test device
default-configs/s390x-softmmu.mak | 1 +
hw/s390x/Kconfig | 3 +
hw/s390x/Makefile.objs| 1 +
hw/s390x/ccw-pong.c | 134
*
functions the host opens access to the SCCB shadow at address 0.
Signed-off-by: Pierre Morel
---
hw/s390x/sclp.c | 18 +
include/hw/s390x/sclp.h | 2 ++
target/s390x/kvm.c | 56 -
3 files changed, 75 insertions(+), 1 deletion(-)
diff
this case is completely new.
For B2 instructions we do not have to do anything this just informative.
However, one information is of interrest, a notification that
SIGP(STOP) is sent to stop the CPUs and terminate QEMU.
Pierre Morel (1):
s390x: protvirt: SCLP interpretation
hw/s390x/sclp.c
time.
+} else {
+r = sclp_service_call(env, sccb, code);
+}
+
if (r < 0) {
kvm_s390_program_interrupt(cpu, -r);
} else {
--
Pierre Morel
IBM Lab Boeblingen
On 2019-11-15 15:22, Thomas Huth wrote:
On 14/11/2019 18.17, Pierre Morel wrote:
On 2019-11-14 13:33, Thomas Huth wrote:
On 14/11/2019 11.38, Cornelia Huck wrote:
On Wed, 13 Nov 2019 20:02:33 +0100
Pierre Morel wrote:
Minor nit for $SUBJECT: this isn't a kvm-unit-tests patch, that's just
On 2019-11-15 11:35, Cornelia Huck wrote:
On Thu, 14 Nov 2019 18:42:35 +0100
Pierre Morel wrote:
On 2019-11-14 14:19, Cornelia Huck wrote:
On Thu, 14 Nov 2019 14:02:35 +0100
Halil Pasic wrote:
On Thu, 14 Nov 2019 11:38:23 +0100
Cornelia Huck wrote:
On Wed, 13 Nov 2019 20:02:33
On 2019-11-14 14:19, Cornelia Huck wrote:
On Thu, 14 Nov 2019 14:02:35 +0100
Halil Pasic wrote:
On Thu, 14 Nov 2019 11:38:23 +0100
Cornelia Huck wrote:
On Wed, 13 Nov 2019 20:02:33 +0100
Pierre Morel wrote:
...snip...
We made some different design decisions, while aiming essentially
On 2019-11-14 14:02, Halil Pasic wrote:
On Thu, 14 Nov 2019 11:38:23 +0100
Cornelia Huck wrote:
On Wed, 13 Nov 2019 20:02:33 +0100
Pierre Morel wrote:
Minor nit for $SUBJECT: this isn't a kvm-unit-tests patch, that's just
one consumer :)
And subchannel is one word in s390-speak.
OK
On 2019-11-14 13:33, Thomas Huth wrote:
On 14/11/2019 11.38, Cornelia Huck wrote:
On Wed, 13 Nov 2019 20:02:33 +0100
Pierre Morel wrote:
Minor nit for $SUBJECT: this isn't a kvm-unit-tests patch, that's just
one consumer :)
The PONG device accept two commands: PONG_READ and PONG_WRITE
On 2019-11-14 11:38, Cornelia Huck wrote:
On Wed, 13 Nov 2019 20:02:33 +0100
Pierre Morel wrote:
Minor nit for $SUBJECT: this isn't a kvm-unit-tests patch, that's just
one consumer :)
yes, right.
The PONG device accept two commands: PONG_READ and PONG_WRITE
which allow to read from
The PONG device accept two commands: PONG_READ and PONG_WRITE
which allow to read from and write to an internal buffer of
1024 bytes.
The QEMU device is named ccw-pong.
Signed-off-by: Pierre Morel
---
hw/s390x/Makefile.objs | 1 +
hw/s390x/ccw-pong.c | 186
-by: Pierre Morel
On 9/26/19 4:10 PM, Matthew Rosato wrote:
The fix in dbe9cf606c shrinks the IOMMU memory region to a size
that seems reasonable on the surface, however is actually too
small as it is based against a 0-mapped address space. This
causes breakage with small guests as they can overrun
We use a ClpRspQueryPci structure to hold the information
related to zPCI Function.
This allows us to be ready to support different zPCI functions
and to retrieve the zPCI function information from the host.
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 22
We use a S390PCIGroup structure to hold the information
related to zPCI Function group.
This allows us to be ready to support multiple groups and to retrieve
the group information from the host.
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 42
defined in vfio.h
Signed-off-by: Pierre Morel
---
linux-headers/linux/vfio.h | 14 +++---
linux-headers/linux/vfio_zdev.h | 34 ++
2 files changed, 45 insertions(+), 3 deletions(-)
create mode 100644 linux-headers/linux/vfio_zdev.h
diff --git a/linux
device remains plugged.
Still there are some values we need to virtualize, like
the UID and FID of the zPCI function, and we currently
only allow the refresh bit for the zPCI group flags.
Note that we export the CLP specific definitions in a dedicated
file for clarity.
Pierre Morel (5):
happens
during the search for the information.
Once we retrieved the host device information, we take care to
- use the virtual UID and FID
- Disable all the IOMMU flags we do not support yet.
Just keeping the refresh bit.
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 82
To have a clean separation between s390-pci-bus.h
and s390-pci-inst.h headers we export the PCI CLP
instructions in a dedicated header.
Signed-off-by: Pierre Morel
Reviewed-by: Collin Walling
---
hw/s390x/s390-pci-bus.h | 1 +
hw/s390x/s390-pci-clp.h | 211
On 14/05/2019 13:49, Cornelia Huck wrote:
On Fri, 10 May 2019 16:38:51 +0200
Pierre Morel wrote:
We use a S390PCIGroup structure to hold the information
related to zPCI Function group.
This allows us to be ready to support multiple groups and to retrieve
the group information from the host
On 12/05/2019 20:22, Michael S. Tsirkin wrote:
On Fri, May 10, 2019 at 04:38:49PM +0200, Pierre Morel wrote:
This should be copied from Linux kernel UAPI includes.
Signed-off-by: Pierre Morel
pls add a note which linux version did you sync with.
I will, thanks.
Pierre
---
linux
flags.
Note that we export the CLP specific definitions in a dedicated
file for clarity.
Pierre Morel (5):
vfio: vfio_iommu_type1: linux header place holder
s390: PCI: Creation a header dedicated to PCI CLP
s390: vfio_pci: Use a PCI Group structure
s390: vfio_pci: Use a PCI Function str
To have a clean separation between s390-pci-bus.h
and s390-pci-inst.h headers we export the PCI CLP
instructions in a dedicated header.
Signed-off-by: Pierre Morel
Reviewed-by: Collin Walling
---
hw/s390x/s390-pci-bus.h | 1 +
hw/s390x/s390-pci-clp.h | 211
We use a ClpRspQueryPci structure to hold the information
related to zPCI Function.
This allows us to be ready to support different zPCI functions
and to retrieve the zPCI function information from the host.
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 22
We use a S390PCIGroup structure to hold the information
related to zPCI Function group.
This allows us to be ready to support multiple groups and to retrieve
the group information from the host.
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 42
the refresh bit.
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 80 +++--
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 6df80aa..3b7539c 100644
--- a/hw/s390x/s390-pci
This should be copied from Linux kernel UAPI includes.
Signed-off-by: Pierre Morel
---
linux-headers/linux/vfio.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index 12a7b1d..eaecaef 100644
+ b/include/hw/s390x/css.h
@@ -97,6 +97,7 @@ typedef struct CcwDataStream {
int (*op_handler)(struct CcwDataStream *cds, void *buff, int len,
CcwDataStreamOp op);
hwaddr cda;
+bool do_skip;
} CcwDataStream;
/*
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
On 15/02/2019 14:52, David Hildenbrand wrote:
On 14.02.19 13:14, Pierre Morel wrote:
A new CPU model facilities is introduced to support AP devices
interruption interception for a KVM guest.
This sentence is confusing. At first I thought you would introduce a new
_fake_ facility.
"Let'
eing added to the
BusState structure to keep track of the number of children plugged
into the
bus. It will be incremented when a child is plugged, and decremented
when a
child is unplugged.
Signed-off-by: Tony Krowiak
Reviewed-by: Pierre Morel
Reviewed-by: Halil Pasic
---
hw/core/qdev.c | 3 +++
On 15/02/2019 10:58, Christian Borntraeger wrote:
On 15.02.2019 10:53, Pierre Morel wrote:
On 14/02/2019 13:14, Pierre Morel wrote:
A new CPU model facilities is introduced to support AP devices
interruption interception for a KVM guest.
"APQI" for "AP-Queue Interru
On 14/02/2019 13:14, Pierre Morel wrote:
A new CPU model facilities is introduced to support AP devices
interruption interception for a KVM guest.
"APQI" for "AP-Queue Interruption" facility
The S390_FEAT_AP_QUEUE_INTERRUPT_CONTROL, CPU facility indicates
whether
looks something like this:
qemu-system-s390x ... -cpu xxx,apqi=on ...
Signed-off-by: Pierre Morel
Reviewed-by: Tony Krowiak
Reviewed-by: Christian Borntraeger
Reviewed-by: Halil Pasic
---
target/s390x/cpu_features.c | 1 +
target/s390x/cpu_features_def.h | 1 +
target/s390x/cpu_models.c
-s390x ... -cpu xxx,apqi=on ...
Pierre Morel (1):
s390x/cpumodel: Set up CPU model for AQIC interception
target/s390x/cpu_features.c | 1 +
target/s390x/cpu_features_def.h | 1 +
target/s390x/cpu_models.c | 1 +
target/s390x/gen-features.c | 1 +
4 files changed, 4 insertions
On 29/01/2019 16:14, David Hildenbrand wrote:
On 29.01.19 14:31, Pierre Morel wrote:
On 21/01/2019 14:42, David Hildenbrand wrote:
PCI on s390x is really weird and how it was modeled in QEMU might not have
been the right choice. Anyhow, right now it is the case that:
- Hotplugging a PCI device
On 29/01/2019 16:11, David Hildenbrand wrote:
On 29.01.19 14:50, Pierre Morel wrote:
On 29/01/2019 11:24, David Hildenbrand wrote:
I'm wondering what the architecture says regarding those events -- can
someone with access to the documentation comment?
Ping. Any comments from the IBM folks
in my point of view more sense.
To me too, (and during hot unplug too) but it has a sense only if we
wait some time between the demand to relinquish the device and the rip
off of the device.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
the guest any possibility to smoothly
relinquish a device.
Is it possible the other way around?
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
On 24/01/2019 11:19, Cornelia Huck wrote:
On Thu, 24 Jan 2019 11:08:02 +0100
Pierre Morel wrote:
On 23/01/2019 11:21, Cornelia Huck wrote:
On Tue, 22 Jan 2019 19:33:46 +0100
Halil Pasic wrote:
On Mon, 21 Jan 2019 12:03:51 +0100
Cornelia Huck wrote:
--- a/drivers/s390/cio
ing series
based on the last comment I got?
I would take into account that the asynchronous commands will come with
your patch series and only provide the framework changes.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
On 16/01/2019 15:50, Halil Pasic wrote:
On Wed, 16 Jan 2019 15:16:44 +0100
Pierre Morel wrote:
On 16/01/2019 13:40, Halil Pasic wrote:
On Tue, 15 Jan 2019 10:35:42 -0500
Collin Walling wrote:
On 1/10/19 8:00 AM, Pierre Morel wrote:
The size of the accessible iommu memory region
On 16/01/2019 13:40, Halil Pasic wrote:
On Tue, 15 Jan 2019 10:35:42 -0500
Collin Walling wrote:
On 1/10/19 8:00 AM, Pierre Morel wrote:
The size of the accessible iommu memory region in the guest
is given to the IOMMU by the guest through the mpcifc request
specifying the PCI Base Address
On 15/01/2019 16:47, Cornelia Huck wrote:
On Thu, 10 Jan 2019 14:00:07 +0100
Pierre Morel wrote:
The size of the accessible iommu memory region in the guest
is given to the IOMMU by the guest through the mpcifc request
specifying the PCI Base Address and the PCI Address Limit.
Let set
ially, but as I don't have
access to the architecture I have to rely on that this works :)
Yep, let's wait for feedback from folks with architecture access.
Works fine on the architecture too.
Seems the logical thing to do for me.
Reviewed-by: Pierre Morel
Signed-off-by: David Hildenbrand
On 14/01/2019 10:23, David Hildenbrand wrote:
On 14.01.19 10:18, Pierre Morel wrote:
On 09/01/2019 12:43, David Hildenbrand wrote:
On 09.01.19 12:29, David Hildenbrand wrote:
On 08.01.19 18:37, Pierre Morel wrote:
From: Yi Min Zhao
Common function measurement block is used to report zPCI
On 09/01/2019 12:43, David Hildenbrand wrote:
On 09.01.19 12:29, David Hildenbrand wrote:
On 08.01.19 18:37, Pierre Morel wrote:
From: Yi Min Zhao
Common function measurement block is used to report zPCI internal
counters of successful pcilg/stg/stb and rpcit instructions to
a memory
The size of the accessible iommu memory region in the guest
is given to the IOMMU by the guest through the mpcifc request
specifying the PCI Base Address and the PCI Address Limit.
Let set the size of the IOMMU region to:
(PCI Address Limit) - (PCI Base Address) + 1.
Signed-off-by: Pierre
Changed the subject (kept only in cover letter)
Changed the commit message to specify that the PAL/PBA values are
given by the guest through the mpcifc call.
Pierre Morel (1):
s390x/pci: Set the iommu region size mpcifc request
hw/s390x/s390-pci-bus.c | 2 +-
1 file changed, 1 insertion
On 09/01/2019 13:59, Cornelia Huck wrote:
On Tue, 8 Jan 2019 18:33:39 +0100
Pierre Morel wrote:
The size of the accessible iommu memory region in the guest
is calculated by the gues as:
s/gues/guest/
(PCI Address Limit) - (PCI Base Address) + 1.
Let's use this value to limit
- You will need the according Linux patch to test this.
2- I am really not happy to add S390 dedicated code in the
VFIO common code, as do SPAPR, but I did not find a better
solution.
Any idea?
Pierre Morel (3):
vfio: Linux header placeholder
vfio/pci: Get real IOMMU information from
When the vfio_iommu_type1 supports the VFIO_IOMMU_INFO_CAPABILITIES
and the capability ID VFIO_IOMMU_INFO_CAP_DMA we can use an ioctl
to retrieve this information from the real IOMMU device.
Let's use this information to add the host window associated with
the container.
Signed-off-by: Pierre
This is a place holder for VFIO.h as changed by the Linux patch
associated with this QEMU series.
Signed-off-by: Pierre Morel
---
linux-headers/linux/vfio.h | 65 +++---
1 file changed, 62 insertions(+), 3 deletions(-)
diff --git a/linux-headers/linux
the real IOMMU associated with the VFIO container.
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 2 +-
hw/s390x/s390-pci-bus.h | 3 +++
hw/s390x/s390-pci-inst.c | 20 +---
hw/vfio/common.c | 4 +++-
include/hw/vfio/vfio-common.h | 3 +++
5
) in the FIB (Function
Information Block) when it issues a Modify PCI Function Control
instruction to switch off FMB and stop the corresponding timer.
Signed-off-by: Yi Min Zhao
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 4 +-
hw/s390x/s390-pci-bus.h | 29 +++
hw/s390x
After the last review round I and use the sizeof of the source entry
in the fmb_do_update() function instead of the target entry.
Anyway they both are the same size but it may be easier to read.
Regards,
Pierre
Yi Min Zhao (1):
s390x/pci: add common function measurement block
The size of the accessible iommu memory region in the guest
is calculated by the gues as:
(PCI Address Limit) - (PCI Base Address) + 1.
Let's use this value to limit the IOMMU region size.
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 2 +-
1 file changed, 1 insertion(+), 1
On 07/01/2019 12:30, David Hildenbrand wrote:
On 03.01.19 11:17, Pierre Morel wrote:
From: Yi Min Zhao
Common function measurement block is used to report zPCI internal
counters of successful pcilg/stg/stb and rpcit instructions to
a memory location provided by the program.
This patch
On 07/01/2019 10:11, Thomas Huth wrote:
On 2019-01-07 10:08, Pierre Morel wrote:
On 04/01/2019 15:39, Cornelia Huck wrote:
On Thu, 3 Jan 2019 11:17:00 +0100
Pierre Morel wrote:
+static void fmb_update(void *opaque)
+{
+ S390PCIBusDevice *pbdev = opaque;
+ int64_t t
On 04/01/2019 15:39, Cornelia Huck wrote:
On Thu, 3 Jan 2019 11:17:00 +0100
Pierre Morel wrote:
+static void fmb_update(void *opaque)
+{
+S390PCIBusDevice *pbdev = opaque;
+int64_t t = qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL);
+int i;
+
+/* Update U bit */
+pbdev
) in the FIB (Function
Information Block) when it issues a Modify PCI Function Control
instruction to switch off FMB and stop the corresponding timer.
Signed-off-by: Yi Min Zhao
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 4 +-
hw/s390x/s390-pci-bus.h | 29 +++
hw/s390x
After the last review round I corrected the commit message
and use the sizeof of the target entries in the fmb_di_update()
function instead of the uint definition.
Regards,
Pierre
Yi Min Zhao (1):
s390x/pci: add common function measurement block
hw/s390x/s390-pci-bus.c | 4 +-
On 19/12/2018 15:22, Cornelia Huck wrote:
On Wed, 19 Dec 2018 13:57:05 +0100
Pierre Morel wrote:
From: Yi Min Zhao
Common function measurement block is used to report zPCI internal
counters of successful pcilg/stg/stb and rpcit instructions to
a memory location provided by the program
) in the FIB (Function
Information Block) when it issues a Modify PCI Function Control
instruction to switch off FMB and stop the corresponding timer.
Signed-off-by: Yi Min Zhao
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 4 +-
hw/s390x/s390-pci-bus.h | 29 +++
hw/s390x
After the last review round I corrected the commit message
and use the sizeof of the target entries in the fmb_di_update()
function.
Regards,
Pierre
Yi Min Zhao (1):
s390x/pci: add common function measurement block
hw/s390x/s390-pci-bus.c | 4 +-
hw/s390x/s390-pci-bus.h | 29 +++
On 19/12/2018 10:48, Cornelia Huck wrote:
On Tue, 18 Dec 2018 18:28:59 +0100
Pierre Morel wrote:
From: Yi Min Zhao
Common function measurement block is used to report zPCI internal
counters of successful pcilg/stg/stb and rpcit instructions to
a memory location provided by the program
) in the FIB (Function
Information Block) when it issues a Modify PCI Function Control
instruction to switch off FMB and stop the corresponding timer.
Signed-off-by: Yi Min Zhao
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 4 +-
hw/s390x/s390-pci-bus.h | 29 +++
hw/s390x
After the last review round I suppressed the fmb_do_update64()
function to have only one single fmb_do_update() to handle
all cases 1,2,4 or 8 bytes.
Patch is tested (for the good case) on Z(KVM) and X(TCG).
Yi Min Zhao (1):
s390x/pci: add common function measurement block
On 18/12/2018 10:55, Cornelia Huck wrote:
On Fri, 14 Dec 2018 17:53:42 +0100
Pierre Morel wrote:
From: Yi Min Zhao
Common function measurement block is used to report zPCI internal
counters of successful pcilg/stg/stb and rpcit instructions to
a memory location provided by the program
address) in the FIB (Function
Information Block) when it issues a Modify PCI Function Control
instrcuction to switch off FMB and stop the corresponding timer.
Signed-off-by: Yi Min Zhao
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 4 +-
hw/s390x/s390-pci-bus.h | 29 ++
hw
After the last review round I worked on endianness.
Doing this I found some errors in the code and in the interpretation
of the documentation.
The new patch changed the following from previous version:
In s390-pci-bus:
- Initialize the FMB Format.
In s390-pci-bus.h
- re-organization of the
On 14/12/2018 15:20, Cornelia Huck wrote:
On Fri, 14 Dec 2018 15:11:18 +0100
Pierre Morel wrote:
From: Yi Min Zhao
Common function measurement block is used to report zPCI internal
counters of successful pcilg/stg/stb and rpcit instructions to
a memory location provided by the program
address) in the FIB (Function
Information Block) when it issues a Modify PCI Function Control
instrcuction to switch off FMB and stop the corresponding timer.
Signed-off-by: Yi Min Zhao
Signed-off-by: Pierre Morel
---
hw/s390x/s390-pci-bus.c | 4 +-
hw/s390x/s390-pci-bus.h | 29 ++
hw
he problem is that the max_index is not the
right measure to determine the number of devices currently plugged.
With the comment amended in this direction:
Reviewed-by: Pierre Morel
(resent after address correction)
Signed-off-by: Tony Krowiak
---
hw/core/qdev.c | 3 +++
inc
he problem is that the max_index is not the
right measure to determine the number of devices currently plugged.
With the comment amended in this direction:
Reviewed-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
hw/core/qdev.c | 3 +++
include/hw/qdev-core.h | 1 +
qdev-monitor.c
On 30/11/2018 16:58, Tony Krowiak wrote:
On 11/30/18 4:31 AM, Pierre Morel wrote:
On 29/11/2018 21:42, Tony Krowiak wrote:
On 11/22/18 11:35 AM, Pierre Morel wrote:
Two good reasons to use the base device as a child of the
AP BUS:
- We can easily find the device without traversing the qtree
On 29/11/2018 16:55, Halil Pasic wrote:
On Thu, 22 Nov 2018 17:35:49 +0100
Pierre Morel wrote:
This series has 3 different type of patches:
The first two:
s390x/vfio: ap: Finding the AP bridge
s390x/vfio: ap: Use the APdevice as a child of the APBus
Are dealing with the QEMU Object
On 30/11/2018 10:31, Pierre Morel wrote:
On 29/11/2018 21:42, Tony Krowiak wrote:
On 11/22/18 11:35 AM, Pierre Morel wrote:
Two good reasons to use the base device as a child of the
AP BUS:
- We can easily find the device without traversing the qtree.
- In case we have different APdevice
On 29/11/2018 22:53, Tony Krowiak wrote:
On 11/22/18 11:35 AM, Pierre Morel wrote:
We intercept the PQAP(AQIC) instruction and transform
...
+static int ap_pqap_aqic(CPUS390XState *env)
+{
+ uint64_t g_nib = env->regs[2];
+ uint8_t apid = ap_reg_get_apid(env->regs[0]);
+ u
On 29/11/2018 21:42, Tony Krowiak wrote:
On 11/22/18 11:35 AM, Pierre Morel wrote:
Two good reasons to use the base device as a child of the
AP BUS:
- We can easily find the device without traversing the qtree.
- In case we have different APdevice instantiation, VFIO with
interception
a response to Thomas.
Otherwise have you any remark?
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
On 29/11/2018 21:30, Tony Krowiak wrote:
On 11/22/18 11:35 AM, Pierre Morel wrote:
In the case we will enter QEMU through interception of instructions,
we will need to retrieve the AP devices.
The base device is the AP bridge.
Let us implement a way to retrieve the AP Bridge from qtree
On 29/11/2018 16:11, Cornelia Huck wrote:
On Thu, 29 Nov 2018 10:02:24 -0500
Tony Krowiak wrote:
On 11/29/18 6:45 AM, Cornelia Huck wrote:
On Thu, 22 Nov 2018 17:35:51 +0100
Pierre Morel wrote:
diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c
index 65de952..94e5a1a 100644
--- a/hw/vfio/ap.c
On 29/11/2018 12:45, Cornelia Huck wrote:
On Thu, 22 Nov 2018 17:35:51 +0100
Pierre Morel wrote:
Two good reasons to use the base device as a child of the
AP BUS:
- We can easily find the device without traversing the qtree.
- In case we have different APdevice instantiation, VFIO
On 26/11/2018 10:58, Cornelia Huck wrote:
On Fri, 23 Nov 2018 15:13:12 +0100
Pierre Morel wrote:
On 22/11/2018 17:54, Cornelia Huck wrote:
A vfio-ccw device may provide an async command subregion for
issuing halt/clear subchannel requests. If it is present, use
it for sending halt/clear
}
LBTM (does that exist? Look Better To Me)
Reviewed-by: Pierre Morel
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
168 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -2,9 +2,12 @@
* vfio based subchannel assignment support
*
* Copyright 2017 IBM Corp.
+ * Copyright 2018 Red Hat, Inc.
+ *
* Author(s): Dong Jia Shi
*Xiao Feng Ren
*Pierre Morel
+ *Cornelia Huck
H (1 << 1)
+struct ccw_cmd_region {
+ __u32 command;
+ __u32 ret_code;
+} __attribute__((packed));
+
#endif
LGTM
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
On 23/11/2018 13:45, Cornelia Huck wrote:
On Fri, 23 Nov 2018 13:28:25 +0100
Pierre Morel wrote:
On 22/11/2018 17:54, Cornelia Huck wrote:
Allow to extend the regions used by vfio-ccw. The first user will be
handling of halt and clear subchannel.
Signed-off-by: Cornelia Huck
---
drivers
cmd_region->ret_code)
+ goto err_out;
+
+ return;
+
+err_out:
+ private->state = state;
+}
+
...snip...
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
14d328338ce2..08eb10283b18 100644
--- a/drivers/s390/cio/ioasm.c
+++ b/drivers/s390/cio/ioasm.c
@@ -233,6 +233,7 @@ int hsch(struct subchannel_id schid)
return ccode;
}
+EXPORT_SYMBOL(hsch);
static inline int __xsch(struct subchannel_id schid)
{
LGTM
Reviewed-by: Pierre Morel
superfluous?
What is the reason not to use simple ioctls ?
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
Let's define the AP adapter type to use it with standard
adapter interface
Signed-off-by: Pierre Morel
---
include/hw/s390x/css.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h
index aae19c4..9946492 100644
--- a/include/hw/s390x/css.h
+++ b
=on ...
Signed-off-by: Pierre Morel
---
target/s390x/cpu_features.c | 1 +
target/s390x/cpu_features_def.h | 1 +
target/s390x/cpu_models.c | 1 +
target/s390x/gen-features.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/target/s390x/cpu_features.c b/target/s390x
This file would be copied from Linux,
I put it here for the review.
Signed-off-by: Pierre Morel
---
linux-headers/linux/vfio.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index ceb6453..d5d10bc9 100644
the adapter
- and use a VFIO ioctl to let the VFIO-AP driver handle the host
instruction associated with the intercepted guest instruction.
This patch serie can be tested with the Linux/KVM patch series
for the VFIO-AP driver: "s390: vfio: ap: Using GISA for AP Interrupt"
Pierre Morel (6
601 - 700 of 915 matches
Mail list logo
