All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org
Cc: ncmike@ncultra.org, qemu-ppc@nongnu.org, agraf@suse.de,
	tyreld@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 07/12] spapr_pci: add ibm, configure-connector RTAS interface
Date: Thu, 04 Sep 2014 22:03:24 -0500	[thread overview]
Message-ID: <540927FC.6010201@linux.vnet.ibm.com> (raw)
In-Reply-To: <53FC4F81.8090204@ozlabs.ru>

On 08/26/2014 04:12 AM, Alexey Kardashevskiy wrote:
> On 08/19/2014 10:21 AM, Michael Roth wrote:
>> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> 
> I have totally no idea what this patch actually does :) When is this rtas
> call made? Once after the guest received the check exception interrupt? Is
> it all it does is fetching the copy of the device tree made by
> spapr_create_drc_phb_dt_entries()? If it is,
> spapr_create_drc_phb_dt_entries() could compose the structure below at the
> first place without any additional conversions, no?

This is one of those functions that I wished never existed, but unfortunately
its one we have to have.

For pseries the hotplug flow includes a step where the guest makes the rtas
configure-connector call to get the new pieces of the device tree that are
added to the guests device tree as a result of adding a pci adapter (and later
for cpu and memory).

This happens after the check exception interrupt. In the guest we determine the
drc index for the pci device being added, then makes this rtas call to get the
device tree updates.

-Nathan

> 
> 
>> ---
>>  hw/ppc/spapr_pci.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 111 insertions(+)
>>
>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>> index 8d1351d..96a57be 100644
>> --- a/hw/ppc/spapr_pci.c
>> +++ b/hw/ppc/spapr_pci.c
>> @@ -606,6 +606,115 @@ static void rtas_get_sensor_state(PowerPCCPU *cpu, sPAPREnvironment *spapr,
>>      rtas_st(rets, 1, decoded);
>>  }
>>  
>> +/* configure-connector work area offsets, int32_t units */
>> +#define CC_IDX_NODE_NAME_OFFSET 2
>> +#define CC_IDX_PROP_NAME_OFFSET 2
>> +#define CC_IDX_PROP_LEN 3
>> +#define CC_IDX_PROP_DATA_OFFSET 4
>> +
>> +#define CC_VAL_DATA_OFFSET ((CC_IDX_PROP_DATA_OFFSET + 1) * 4)
>> +#define CC_RET_NEXT_SIB 1
>> +#define CC_RET_NEXT_CHILD 2
>> +#define CC_RET_NEXT_PROPERTY 3
>> +#define CC_RET_PREV_PARENT 4
>> +#define CC_RET_ERROR RTAS_OUT_HW_ERROR
>> +#define CC_RET_SUCCESS RTAS_OUT_SUCCESS
> 
> 
> Why these two are here, not in the same bucket as RTAS_OUT_HW_ERROR and others?
> 
> 
>> +
>> +static void rtas_ibm_configure_connector(PowerPCCPU *cpu,
>> +                                         sPAPREnvironment *spapr,
>> +                                         uint32_t token, uint32_t nargs,
>> +                                         target_ulong args, uint32_t nret,
>> +                                         target_ulong rets)
>> +{
>> +    uint64_t wa_addr = ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(args, 0);
>> +    sPAPRDrcEntry *drc_entry = NULL;
>> +    sPAPRConfigureConnectorState *ccs;
>> +    void *wa_buf;
>> +    int32_t *wa_buf_int;
>> +    hwaddr map_len = 0x1024;
>> +    uint32_t drc_index;
>> +    int rc = 0, next_offset, tag, prop_len, node_name_len;
>> +    const struct fdt_property *prop;
>> +    const char *node_name, *prop_name;
>> +
>> +    wa_buf = cpu_physical_memory_map(wa_addr, &map_len, 1);
>> +    if (!wa_buf) {
>> +        rc = CC_RET_ERROR;
>> +        goto error_exit;
>> +    }
>> +    wa_buf_int = wa_buf;
>> +
>> +    drc_index = *(uint32_t *)wa_buf;
>> +    drc_entry = spapr_find_drc_entry(drc_index);
>> +    if (!drc_entry) {
>> +        rc = -1;
>> +        goto error_exit;
>> +    }
>> +
>> +    ccs = &drc_entry->cc_state;
>> +    if (ccs->state == CC_STATE_PENDING) {
>> +        /* fdt should've been been attached to drc_entry during
>> +         * realize/hotplug
>> +         */
>> +        g_assert(ccs->fdt);
>> +        ccs->depth = 0;
>> +        ccs->offset = ccs->offset_start;
>> +        ccs->state = CC_STATE_ACTIVE;
>> +    }
>> +
>> +    if (ccs->state == CC_STATE_IDLE) {
>> +        rc = -1;
>> +        goto error_exit;
>> +    }
>> +
>> +retry:
>> +    tag = fdt_next_tag(ccs->fdt, ccs->offset, &next_offset);
>> +
>> +    switch (tag) {
>> +    case FDT_BEGIN_NODE:
>> +        ccs->depth++;
>> +        node_name = fdt_get_name(ccs->fdt, ccs->offset, &node_name_len);
>> +        wa_buf_int[CC_IDX_NODE_NAME_OFFSET] = CC_VAL_DATA_OFFSET;
>> +        strcpy(wa_buf + wa_buf_int[CC_IDX_NODE_NAME_OFFSET], node_name);
>> +        rc = CC_RET_NEXT_CHILD;
>> +        break;
>> +    case FDT_END_NODE:
>> +        ccs->depth--;
>> +        if (ccs->depth == 0) {
>> +            /* reached the end of top-level node, declare success */
>> +            ccs->state = CC_STATE_PENDING;
>> +            rc = CC_RET_SUCCESS;
>> +        } else {
>> +            rc = CC_RET_PREV_PARENT;
>> +        }
>> +        break;
>> +    case FDT_PROP:
>> +        prop = fdt_get_property_by_offset(ccs->fdt, ccs->offset, &prop_len);
>> +        prop_name = fdt_string(ccs->fdt, fdt32_to_cpu(prop->nameoff));
>> +        wa_buf_int[CC_IDX_PROP_NAME_OFFSET] = CC_VAL_DATA_OFFSET;
>> +        wa_buf_int[CC_IDX_PROP_LEN] = prop_len;
>> +        wa_buf_int[CC_IDX_PROP_DATA_OFFSET] =
>> +            CC_VAL_DATA_OFFSET + strlen(prop_name) + 1;
>> +        strcpy(wa_buf + wa_buf_int[CC_IDX_PROP_NAME_OFFSET], prop_name);
>> +        memcpy(wa_buf + wa_buf_int[CC_IDX_PROP_DATA_OFFSET],
>> +               prop->data, prop_len);
>> +        rc = CC_RET_NEXT_PROPERTY;
>> +        break;
>> +    case FDT_END:
>> +        rc = CC_RET_ERROR;
>> +        break;
>> +    default:
>> +        ccs->offset = next_offset;
>> +        goto retry;
> 
> Could be a while(1) loop...
> 
> 
>> +    }
>> +
>> +    ccs->offset = next_offset;
>> +
>> +error_exit:
>> +    cpu_physical_memory_unmap(wa_buf, 0x1024, 1, 0x1024);
> 
> 
> 0x1024 is weird constant, are you sure about that?
> 
> 
>> +    rtas_st(rets, 0, rc);
>> +}
>> +
>>  static int pci_spapr_swizzle(int slot, int pin)
>>  {
>>      return (slot + pin) % PCI_NUM_PINS;
>> @@ -1276,6 +1385,8 @@ void spapr_pci_rtas_init(void)
>>                          rtas_get_power_level);
>>      spapr_rtas_register(RTAS_GET_SENSOR_STATE, "get-sensor-state",
>>                          rtas_get_sensor_state);
>> +    spapr_rtas_register(RTAS_IBM_CONFIGURE_CONNECTOR, "ibm,configure-connector",
>> +                        rtas_ibm_configure_connector);
>>  }
>>  
>>  static void spapr_pci_register_types(void)
>>
> 
> 

  reply	other threads:[~2014-09-05  3:03 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19  0:21 [Qemu-devel] [PATCH v3 00/12] spapr: add support for pci hotplug Michael Roth
2014-08-19  0:21 ` [Qemu-devel] [PATCH 01/12] spapr: populate DRC entries for root dt node Michael Roth
2014-08-26  7:55   ` Alexey Kardashevskiy
2014-08-26  8:24     ` Alexey Kardashevskiy
2014-08-26 15:25       ` Michael Roth
2014-08-26 15:41         ` Michael Roth
2014-08-29 18:27         ` Tyrel Datwyler
2014-08-29 23:15           ` Alexander Graf
2014-08-26 14:56     ` Michael Roth
2014-09-05  0:31     ` [Qemu-devel] [Qemu-ppc] " Tyrel Datwyler
2014-08-26 11:11   ` [Qemu-devel] " Alexander Graf
2014-08-26 16:47     ` Michael Roth
2014-08-26 17:16       ` Alexander Graf
2014-09-03  5:55   ` Bharata B Rao
2014-09-05 22:00   ` Tyrel Datwyler
2014-08-19  0:21 ` [Qemu-devel] [PATCH 02/12] spapr_pci: populate DRC dt entries for PHBs Michael Roth
2014-08-26  8:32   ` Alexey Kardashevskiy
2014-08-26 17:16     ` Michael Roth
2014-08-26  9:09   ` Alexey Kardashevskiy
2014-08-26 17:52     ` Michael Roth
2014-08-26 11:29   ` Alexander Graf
2014-08-26 18:30     ` Michael Roth
2014-08-19  0:21 ` [Qemu-devel] [PATCH 03/12] spapr: add helper to retrieve a PHB/device DrcEntry Michael Roth
2014-08-19  0:21 ` [Qemu-devel] [PATCH 04/12] spapr_pci: add set-indicator RTAS interface Michael Roth
2014-08-26 11:36   ` Alexander Graf
2014-09-05  2:55     ` Nathan Fontenot
2014-09-30 22:08     ` Michael Roth
2014-10-01 14:30       ` Alexander Graf
2014-11-26  4:51         ` Bharata B Rao
2014-11-26  4:54         ` Bharata B Rao
2014-11-26  6:27           ` Michael Roth
2014-12-01  4:57             ` Bharata B Rao
2014-12-23 15:12               ` Michael Roth
2015-01-01  6:35                 ` Bharata B Rao
2014-08-19  0:21 ` [Qemu-devel] [PATCH 05/12] spapr_pci: add get/set-power-level RTAS interfaces Michael Roth
2014-08-19  0:21 ` [Qemu-devel] [PATCH 06/12] spapr_pci: add get-sensor-state RTAS interface Michael Roth
2014-09-05  0:34   ` Tyrel Datwyler
2014-08-19  0:21 ` [Qemu-devel] [PATCH 07/12] spapr_pci: add ibm, configure-connector " Michael Roth
2014-08-26  9:12   ` Alexey Kardashevskiy
2014-09-05  3:03     ` Nathan Fontenot [this message]
2014-08-26 11:39   ` Alexander Graf
2014-08-19  0:21 ` [Qemu-devel] [PATCH 08/12] pci: allow 0 address for PCI IO regions Michael Roth
2014-08-26  9:14   ` Alexey Kardashevskiy
2014-08-26 11:55     ` Peter Maydell
2014-08-26 18:34     ` Michael Roth
2014-08-26 11:41   ` Alexander Graf
2014-08-27 13:47   ` Michael S. Tsirkin
2014-08-28 21:21     ` Michael Roth
2014-08-28 21:33       ` Peter Maydell
2014-08-28 21:46         ` Michael S. Tsirkin
2014-08-19  0:21 ` [Qemu-devel] [PATCH 09/12] spapr_pci: enable basic hotplug operations Michael Roth
2014-08-26  9:40   ` Alexey Kardashevskiy
2014-08-26 12:30   ` Alexander Graf
2014-09-03 10:33   ` Bharata B Rao
2014-09-03 23:03     ` Michael Roth
2014-09-04 15:08       ` Bharata B Rao
2014-09-04 16:12         ` Michael Roth
2014-09-04 16:34           ` Michael Roth
2014-09-05  3:10             ` Nathan Fontenot
2014-09-05 17:17               ` [Qemu-devel] [Qemu-ppc] " Tyrel Datwyler
2014-08-19  0:21 ` [Qemu-devel] [PATCH 10/12] spapr_events: re-use EPOW event infrastructure for hotplug events Michael Roth
2014-08-26  9:28   ` Alexey Kardashevskiy
2014-08-19  0:21 ` [Qemu-devel] [PATCH 11/12] spapr_events: event-scan RTAS interface Michael Roth
2014-08-26  9:30   ` Alexey Kardashevskiy
2014-08-29 18:43     ` Tyrel Datwyler
2014-08-19  0:21 ` [Qemu-devel] [PATCH 12/12] spapr_pci: emit hotplug add/remove events during hotplug Michael Roth
2014-08-26  9:35   ` Alexey Kardashevskiy
2014-08-26 12:36   ` Alexander Graf
2014-08-26  9:24 ` [Qemu-devel] [PATCH v3 00/12] spapr: add support for pci hotplug Alexey Kardashevskiy

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=540927FC.6010201@linux.vnet.ibm.com \
    --to=nfont@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=ncmike@ncultra.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=tyreld@linux.vnet.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.