qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [PATCH v2 1/6] s390x/vfio: ap: Finding the AP bridge


From: Pierre Morel
Subject: Re: [qemu-s390x] [PATCH v2 1/6] s390x/vfio: ap: Finding the AP bridge
Date: Fri, 30 Nov 2018 10:09:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

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.

Signed-off-by: Pierre Morel <address@hidden>
---
  hw/s390x/ap-bridge.c         | 12 ++++++++++++
  include/hw/s390x/ap-bridge.h |  1 +
  2 files changed, 13 insertions(+)

diff --git a/hw/s390x/ap-bridge.c b/hw/s390x/ap-bridge.c
index 3795d30..831ad5d 100644
--- a/hw/s390x/ap-bridge.c
+++ b/hw/s390x/ap-bridge.c
@@ -14,6 +14,18 @@
  #include "hw/s390x/ap-bridge.h"
  #include "cpu.h"
+DeviceState *s390_get_ap_bridge(void)
+{
+    static DeviceState *apb;

Since you are caching a reference to the bridge after
retrieving it, why not make apb a global scope variable
and initialize it in s390_init_ap() when the bridge is
created. You can then declare it as an extern in the
ap-bridge.h header file and you eliminate the need for
this function. If you do make it a global var, I would
name it ap_bridge;

We already had this discussion when implementing zPCI.
I use a similar solution as it was decided at that time.


Regards,
Pierre


--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany




reply via email to

[Prev in Thread] Current Thread [Next in Thread]