qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH qemu v22] spapr: Implement Open Firmware client interface
Date: Thu, 8 Jul 2021 14:07:17 +1000	[thread overview]
Message-ID: <YOZ59azHunGLT2v0@yekko> (raw)
In-Reply-To: <377380cb-64cb-9bde-82c3-7dfcdf3210c6@ozlabs.ru>

[-- Attachment #1: Type: text/plain, Size: 8820 bytes --]

On Thu, Jul 08, 2021 at 01:15:10PM +1000, Alexey Kardashevskiy wrote:
> 
> 
> On 08/07/2021 12:40, David Gibson wrote:
> > On Fri, Jun 25, 2021 at 03:51:55PM +1000, Alexey Kardashevskiy wrote:
[snip]
> > > +void spapr_vof_client_dt_finalize(SpaprMachineState *spapr, void *fdt)
> > > +{
> > > +    char *stdout_path = spapr_vio_stdout_path(spapr->vio_bus);
> > > +    int chosen;
> > > +
> > > +    vof_build_dt(fdt, spapr->vof);
> > > +
> > > +    _FDT(chosen = fdt_path_offset(fdt, "/chosen"));
> > > +    _FDT(fdt_setprop_string(fdt, chosen, "bootargs",
> > > +                            spapr->vof->bootargs ? : ""));
> > 
> > You do several things with vof->bootargs, but if you've initialized it
> > from machine->kernel_cmdline, I didn't spot it.
> 
> 
> GRUB initilizes it and updates via spapr_vof_setprop().

Right, but my point is if an OF client doesn't poke it, it should have
the value from qemu's -append option which is in
machine->kernel_cmdline.

[snip]
> > > +static int path_offset(const void *fdt, const char *path)
> > > +{
> > > +    g_autofree char *p = NULL;
> > > +    char *at;
> > > +
> > > +    /*
> > > +     * https://www.devicetree.org/open-firmware/bindings/ppc/release/ppc-2_1.html#HDR16
> > > +     *
> > > +     * "Conversion from numeric representation to text representation shall use
> > > +     * the lower case forms of the hexadecimal digits in the range a..f,
> > > +     * suppressing leading zeros".
> > 
> > Huh... that suggests that Zoltan's firmware which passes a caps hex
> > and expects it to work is doing the wrong thing.  We still need to
> > accomodate it, though.
> > 
> > > +     */
> > > +    at = strchr(path, '@');
> > > +    if (!at) {
> > > +        return fdt_path_offset(fdt, path);
> > > +    }
> > > +
> > > +    p = g_strdup(path);
> > > +    for (at = at - path + p + 1; *at; ++at) {
> > > +        *at = tolower(*at);
> > > +    }
> > 
> > This isn't quite right, though we might get away with it in practice.
> > You're taking a whole path here, and each path component could
> > potentially have a unit address.  This will tolower() everything after
> > the first @, potentially case mangling the base names of later
> > components.
> 
> Ah. I need the last "@" here, at least. But I do not think we need to go any
> further than this here.

That's closer to correct, and will probably work in practice.  That
will fail, though, if we find a client that uses bad caps for an
intermediate path component.

[snip]
> > > +static uint32_t vof_setprop(MachineState *ms, void *fdt, Vof *vof,
> > > +                            uint32_t nodeph, uint32_t pname,
> > > +                            uint32_t valaddr, uint32_t vallen)
> > > +{
> > > +    char propname[OF_PROPNAME_LEN_MAX + 1];
> > > +    uint32_t ret = -1;
> > > +    int offset;
> > > +    char trval[64] = "";
> > > +    char nodepath[VOF_MAX_PATH] = "";
> > > +    Object *vmo = object_dynamic_cast(OBJECT(ms), TYPE_VOF_MACHINE_IF);
> > > +    g_autofree char *val = NULL;
> > > +
> > > +    if (vallen > VOF_MAX_SETPROPLEN) {
> > > +        goto trace_exit;
> > > +    }
> > > +    if (readstr(pname, propname, sizeof(propname))) {
> > > +        goto trace_exit;
> > > +    }
> > > +    offset = fdt_node_offset_by_phandle(fdt, nodeph);
> > > +    if (offset < 0) {
> > > +        goto trace_exit;
> > > +    }
> > > +    ret = get_path(fdt, offset, nodepath, sizeof(nodepath));
> > > +    if (ret <= 0) {
> > > +        goto trace_exit;
> > > +    }
> > > +
> > > +    val = g_malloc0(vallen);
> > > +    if (VOF_MEM_READ(valaddr, val, vallen) != MEMTX_OK) {
> > > +        goto trace_exit;
> > > +    }
> > > +
> > > +    if (vmo) {
> > > +        VofMachineIfClass *vmc = VOF_MACHINE_GET_CLASS(vmo);
> > > +
> > > +        if (vmc->setprop &&
> > > +            !vmc->setprop(ms, nodepath, propname, val, vallen)) {
> > > +            goto trace_exit;
> > 
> > This defaults to allowing the setprop if the machine doesn't provide a
> > setprop callback.  I think it would be safer to default to prohibiting
> > all setprops except those the machine explicitly allows.
> 
> 
> Mmmm... I can imagine the client using the device tree as a temporary
> storage. I'd rather add a trace for such cases.

If they do, I think that's something we'll need to consider and
account for that platform, rather than something we want to allow to
begin with.

[snip]
> > > +static uint32_t vof_write(Vof *vof, uint32_t ihandle, uint32_t buf,
> > > +                          uint32_t len)
> > > +{
> > > +    char tmp[VOF_VTY_BUF_SIZE];
> > > +    unsigned cb;
> > > +    OfInstance *inst = (OfInstance *)
> > > +        g_hash_table_lookup(vof->of_instances, GINT_TO_POINTER(ihandle));
> > > +
> > > +    if (!inst) {
> > > +        trace_vof_error_write(ihandle);
> > > +        return -1;
> > > +    }
> > > +
> > > +    for ( ; len > 0; len -= cb) {
> > > +        cb = MIN(len, sizeof(tmp) - 1);
> > > +        if (VOF_MEM_READ(buf, tmp, cb) != MEMTX_OK) {
> > > +            return -1;
> > > +        }
> > > +
> > > +        /* FIXME: there is no backend(s) yet so just call a trace */
> > 
> > Improving that I think should count as a high priority enhancement.
> 
> Heh. This is the main point of opposition to the entire approach :-)


Ah... yeah...


> 
> 
> > 
> > > +        if (trace_event_get_state(TRACE_VOF_WRITE) &&
> > > +            qemu_loglevel_mask(LOG_TRACE)) {
> > > +            tmp[cb] = '\0';
> > > +            trace_vof_write(ihandle, cb, tmp);
> > > +        }
> > > +    }
> > > +
> > > +    return len;
> > > +}
> > 
> > [snip]
> > > +
> > > +static void vof_instantiate_rtas(Error **errp)
> > > +{
> > > +    error_setg(errp, "The firmware should have instantiated RTAS");
> > 
> > Since this always fails...
> > 
> > > +}
> > > +
> > > +static uint32_t vof_call_method(MachineState *ms, Vof *vof, uint32_t methodaddr,
> > > +                                uint32_t ihandle, uint32_t param1,
> > > +                                uint32_t param2, uint32_t param3,
> > > +                                uint32_t param4, uint32_t *ret2)
> > > +{
> > > +    uint32_t ret = -1;
> > > +    char method[VOF_MAX_METHODLEN] = "";
> > > +    OfInstance *inst;
> > > +
> > > +    if (!ihandle) {
> > > +        goto trace_exit;
> > > +    }
> > > +
> > > +    inst = (OfInstance *)g_hash_table_lookup(vof->of_instances,
> > > +                                             GINT_TO_POINTER(ihandle));
> > > +    if (!inst) {
> > > +        goto trace_exit;
> > > +    }
> > > +
> > > +    if (readstr(methodaddr, method, sizeof(method))) {
> > > +        goto trace_exit;
> > > +    }
> > > +
> > > +    if (strcmp(inst->path, "/") == 0) {
> > > +        if (strcmp(method, "ibm,client-architecture-support") == 0) {
> > > +            Object *vmo = object_dynamic_cast(OBJECT(ms), TYPE_VOF_MACHINE_IF);
> > > +
> > > +            if (vmo) {
> > > +                VofMachineIfClass *vmc = VOF_MACHINE_GET_CLASS(vmo);
> > > +
> > > +                g_assert(vmc->client_architecture_support);
> > > +                ret = vmc->client_architecture_support(ms, first_cpu, param1);
> > > +            }
> > > +
> > > +            *ret2 = 0;
> > > +        }
> > > +    } else if (strcmp(inst->path, "/rtas") == 0) {
> > > +        if (strcmp(method, "instantiate-rtas") == 0) {
> > 
> > ... why do you even need to handle it here?
> 
> Well, I do not _need_ it. I was choosing between leaving a comment here or
> adding the code. The same number of lines but the code seemed more
> descriptive. It also helps when I am playing with no-firmware boot when I
> hack the kernel to call H_VOF directly and seeing the error message about is
> better than a weird crash, this is a very minor thing though.

Hm, ok, you convinced me.

[snip]
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 7d9cd2904264..6fb202f99e90 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -1356,6 +1356,18 @@ F: hw/pci-host/mv64361.c
> > >   F: hw/pci-host/mv643xx.h
> > >   F: include/hw/pci-host/mv64361.h
> > > +Virtual Open Firmware (VOF)
> > > +M: Alexey Kardashevskiy <aik@ozlabs.ru>
> > > +M: David Gibson <david@gibson.dropbear.id.au>
> > > +M: Greg Kurz <groug@kaod.org>
> > 
> > I think "R" might be more appropriate for me and Greg, rather than "M".
> 
> Sure. Thanks for the review, I'll try to post the folloup before Monday.
> 
> 
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-07-08  4:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25  5:51 [PATCH qemu v22] spapr: Implement Open Firmware client interface Alexey Kardashevskiy
2021-06-27 16:38 ` BALATON Zoltan
2021-06-28  5:20   ` Alexey Kardashevskiy
2021-07-08  2:40 ` David Gibson
2021-07-08  3:15   ` Alexey Kardashevskiy
2021-07-08  4:07     ` David Gibson [this message]
2021-07-08  6:38   ` Alexey Kardashevskiy
2021-07-08 22:22   ` BALATON Zoltan
2021-07-09  0:57     ` David Gibson

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=YOZ59azHunGLT2v0@yekko \
    --to=david@gibson.dropbear.id.au \
    --cc=aik@ozlabs.ru \
    --cc=groug@kaod.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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).