From: Thomas Huth <thuth@redhat.com>
To: "Cédric Le Goater" <clegoate@redhat.com>,
qemu-s390x@nongnu.org,
"Christian Borntraeger" <borntraeger@linux.ibm.com>
Cc: qemu-devel@nongnu.org, "Halil Pasic" <pasic@linux.ibm.com>,
"Eric Farman" <farman@linux.ibm.com>,
"David Hildenbrand" <david@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: [PATCH] hw/s390x: Attach the sclpconsole to the /machine/sclp node
Date: Tue, 30 Apr 2024 21:06:16 +0200 [thread overview]
Message-ID: <cf84dff2-b2d9-481e-8e54-8fb78dc214b3@redhat.com> (raw)
In-Reply-To: <f958af03-00d3-4d3a-b54b-f060c8fc70df@redhat.com>
On 30/04/2024 16.24, Thomas Huth wrote:
> On 30/04/2024 13.58, Cédric Le Goater wrote:
>> On 4/30/24 10:04, Thomas Huth wrote:
>>> The sclpconsole currently does not have a proper parent in the QOM
>>> tree, so it shows up under /machine/unattached - which is somewhat
>>> ugly. Let's attach it to /machine/sclp instead.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>> include/hw/s390x/sclp.h | 2 +-
>>> hw/s390x/s390-virtio-ccw.c | 11 +++++++----
>>> hw/s390x/sclp.c | 4 +++-
>>> 3 files changed, 11 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h
>>> index b405a387b6..abfd6d8868 100644
>>> --- a/include/hw/s390x/sclp.h
>>> +++ b/include/hw/s390x/sclp.h
>>> @@ -222,7 +222,7 @@ static inline int sccb_data_len(SCCB *sccb)
>>> }
>>> -void s390_sclp_init(void);
>>> +Object *s390_sclp_init(void);
>>> void sclp_service_interrupt(uint32_t sccb);
>>> void raise_irq_cpu_hotplug(void);
>>> int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code);
>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>> index 4dcc213820..e2f9206ded 100644
>>> --- a/hw/s390x/s390-virtio-ccw.c
>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>> @@ -237,11 +237,13 @@ static void s390_create_virtio_net(BusState *bus,
>>> const char *name)
>>> }
>>> }
>>> -static void s390_create_sclpconsole(const char *type, Chardev *chardev)
>>> +static void s390_create_sclpconsole(Object *sclp, const char *type,
>>> + Chardev *chardev)
>>> {
>>> DeviceState *dev;
>>> dev = qdev_new(type);
>>> + object_property_add_child(sclp, type, OBJECT(dev));
>>> qdev_prop_set_chr(dev, "chardev", chardev);
>>> qdev_realize_and_unref(dev, sclp_get_event_facility_bus(),
>>> &error_fatal);
>>> }
>>> @@ -252,8 +254,9 @@ static void ccw_init(MachineState *machine)
>>> int ret;
>>> VirtualCssBus *css_bus;
>>> DeviceState *dev;
>>> + Object *sclp;
>>> - s390_sclp_init();
>>> + sclp = s390_sclp_init();
>>
>> I would simply drop s390_sclp_init(), same for :
>>
>> void s390_init_tod(void);
>> void s390_init_ap(void);
>> void s390_stattrib_init(void);
>> void s390_skeys_init(void);
>> void s390_flic_init(void);
>>
>> These routines all do the same and are not very useful TBH, and I would
>> add pointers under the s390x MachineState possibly.
>
> Some of them seem to do a little bit more things, like checking whether the
> feature is available or not, e.g. s390_init_ap() ... IMHO it makes sense to
> keep at least those?
>
> But for s390_sclp_init ... it could be inlined, indeed, especially if we
> also switch the object_unref + qdev_realize in there into
> qdev_realize_and_unref. Let me try to do that in a v2 ...
Actually, after looking at the code a little bit longer, it seems to me like
the sclpconsole should be attached to /machine/sclp/s390-sclp-event-facility
instead of just /machine/sclp, since the other devices of type
TYPE_SCLP_EVENT are also located there. That makes the patch even easier
since we already have the pointer from sclp_get_event_facility_bus() in that
function.
Thomas
prev parent reply other threads:[~2024-04-30 19:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 8:04 [PATCH] hw/s390x: Attach the sclpconsole to the /machine/sclp node Thomas Huth
2024-04-30 8:19 ` David Hildenbrand
2024-04-30 8:22 ` Thomas Huth
2024-04-30 8:56 ` Philippe Mathieu-Daudé
2024-04-30 11:58 ` Cédric Le Goater
2024-04-30 14:24 ` Thomas Huth
2024-04-30 19:06 ` Thomas Huth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf84dff2-b2d9-481e-8e54-8fb78dc214b3@redhat.com \
--to=thuth@redhat.com \
--cc=armbru@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=clegoate@redhat.com \
--cc=david@redhat.com \
--cc=farman@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).