From: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v13] migration: spapr: migrate pending_events of spapr state
Date: Tue, 23 May 2017 11:54:42 -0300 [thread overview]
Message-ID: <58725da8-411b-e95f-7fb0-85b54c88f224@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170523040750.GS30246@umbus.fritz.box>
On 05/23/2017 01:07 AM, David Gibson wrote:
> On Mon, May 22, 2017 at 03:40:39PM -0300, Daniel Henrique Barboza wrote:
>> From: Jianjun Duan <duanj@linux.vnet.ibm.com>
>>
>> In racing situations between hotplug events and migration operation,
>> a rtas hotplug event could have not yet be delivered to the source
>> guest when migration is started. In this case the pending_events of
>> spapr state need be transmitted to the target so that the hotplug
>> event can be finished on the target.
>>
>> All the different fields of the events are encoded as defined by
>> PAPR. We can migrate them as a binary stream inside VBUFFER without
>> any concerns about data padding or endianess.
>>
>> pending_events is put in a subsection in the spapr state VMSD to make
>> sure migration across different versions is not broken.
>>
>> Signed-off-by: Jianjun Duan <duanj@linux.vnet.ibm.com>
>> Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
>> ---
>> hw/ppc/spapr.c | 32 ++++++++++++++++++++++++++++++++
>> hw/ppc/spapr_events.c | 19 +++++++++++++++++++
>> include/hw/ppc/spapr.h | 3 ++-
>> 3 files changed, 53 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index 75e298b..558f951 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -1453,6 +1453,37 @@ static bool version_before_3(void *opaque, int version_id)
>> return version_id < 3;
>> }
>>
>> +static bool spapr_pending_events_needed(void *opaque)
>> +{
>> + sPAPRMachineState *spapr = (sPAPRMachineState *)opaque;
>> + return !QTAILQ_EMPTY(&spapr->pending_events);
>> +}
>> +
>> +static const VMStateDescription vmstate_spapr_event_entry = {
>> + .name = "spapr_event_log_entry",
>> + .version_id = 1,
>> + .minimum_version_id = 1,
>> + .fields = (VMStateField[]) {
>> + VMSTATE_INT32(log_type, sPAPREventLogEntry),
>> + VMSTATE_UINT32(data_size, sPAPREventLogEntry),
>> + VMSTATE_VBUFFER_ALLOC_UINT32(data, sPAPREventLogEntry, 0,
>> + NULL, data_size),
>> + VMSTATE_END_OF_LIST()
>> + },
>> +};
>> +
>> +static const VMStateDescription vmstate_spapr_pending_events = {
>> + .name = "spapr_pending_events",
>> + .version_id = 1,
>> + .minimum_version_id = 1,
>> + .needed = spapr_pending_events_needed,
>> + .fields = (VMStateField[]) {
>> + VMSTATE_QTAILQ_V(pending_events, sPAPRMachineState, 1,
>> + vmstate_spapr_event_entry, sPAPREventLogEntry, next),
>> + VMSTATE_END_OF_LIST()
>> + },
>> +};
>> +
>> static bool spapr_ov5_cas_needed(void *opaque)
>> {
>> sPAPRMachineState *spapr = opaque;
>> @@ -1551,6 +1582,7 @@ static const VMStateDescription vmstate_spapr = {
>> .subsections = (const VMStateDescription*[]) {
>> &vmstate_spapr_ov5_cas,
>> &vmstate_spapr_patb_entry,
>> + &vmstate_spapr_pending_events,
>> NULL
>> }
>> };
>> diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
>> index 73e2a18..6c42041 100644
>> --- a/hw/ppc/spapr_events.c
>> +++ b/hw/ppc/spapr_events.c
>> @@ -346,10 +346,29 @@ static void rtas_event_log_queue(int log_type, void *data)
>> {
>> sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
>> sPAPREventLogEntry *entry = g_new(sPAPREventLogEntry, 1);
>> + struct epow_log_full *new_epow = NULL;
>> + struct hp_log_full *new_hp = NULL;
>> + uint32_t ext_length = 0;
>>
>> g_assert(data);
>> entry->log_type = log_type;
>> entry->data = data;
>> +
>> + switch (log_type) {
>> + case RTAS_LOG_TYPE_EPOW:
>> + new_epow = (struct epow_log_full *)data;
>> + ext_length = be32_to_cpu(new_epow->hdr.extended_length);
>> + entry->data_size = ext_length + sizeof(new_epow->hdr);
>> + break;
>> + case RTAS_LOG_TYPE_HOTPLUG:
>> + new_hp = (struct hp_log_full *)data;
>> + ext_length = be32_to_cpu(new_hp->hdr.extended_length);
>> + entry->data_size = ext_length + sizeof(new_hp->hdr);
>> + break;
>> + default:
>> + g_assert(false);
>> + }
>> +
> You're still overcomplicating this. Both epow_log_full and
> hp_log_full start with an rtas_error_log header, which is what
> contains the extended_length field. You can just case data directly
> to struct rtas_error_log *, and derive the data size from there.
Yeah this is indeed overcomplicated. Just saw the following in
check_exception():
hdr = event->data;
event_len = be32_to_cpu(hdr->extended_length) + sizeof(*hdr);
Way simpler than what I was doing.
>
> And.. come to think of it, you don't need the log_type in the vmsd
> either, since it can be derived from the summary field in the same
> header.
>
> And.. going even further, we could alter the existing code so that
> instead of embedding the rtas_error_log header in the allocated
> buffer, we could inline it into the sPAPREventLogEntry structure, with
> just the extended data in the variable sized buffer. Then we wouldn't
> need a new data_size field, the extended_size field from the
> rtas_error_log substructure would already be exactly what we need to
> size the buffer.
Sounds good. I'll see what I can do.
Daniel
>
>
>> QTAILQ_INSERT_TAIL(&spapr->pending_events, entry, next);
>> }
>>
>> diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
>> index be2b3b8..b2fcd62 100644
>> --- a/include/hw/ppc/spapr.h
>> +++ b/include/hw/ppc/spapr.h
>> @@ -598,8 +598,9 @@ struct sPAPRTCETable {
>> sPAPRTCETable *spapr_tce_find_by_liobn(target_ulong liobn);
>>
>> struct sPAPREventLogEntry {
>> - int log_type;
>> + int32_t log_type;
>> void *data;
>> + uint32_t data_size;
>> QTAILQ_ENTRY(sPAPREventLogEntry) next;
>> };
>>
prev parent reply other threads:[~2017-05-23 14:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 18:40 [Qemu-devel] [PATCH v13] migration: spapr: migrate pending_events of spapr state Daniel Henrique Barboza
2017-05-22 18:40 ` Daniel Henrique Barboza
2017-05-23 4:07 ` David Gibson
2017-05-23 14:54 ` Daniel Henrique Barboza [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=58725da8-411b-e95f-7fb0-85b54c88f224@linux.vnet.ibm.com \
--to=danielhb@linux.vnet.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=mdroth@linux.vnet.ibm.com \
--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).