All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugene Fedotov <e.fedotov@samsung.com>
To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com
Subject: Re: [PATCH RESEND v5 1/6] xen/arm: Implement hvm save and restore
Date: Wed, 13 Nov 2013 12:00:35 +0400	[thread overview]
Message-ID: <528331A3.8070608@samsung.com> (raw)
In-Reply-To: <1384269316.10204.40.camel@kazak.uk.xensource.com>

12.11.2013 19:15, Ian Campbell  wrote:
> On Fri, 2013-11-08 at 16:50 +0900, Jaeyong Yoo wrote:
>
> If these get resent again please can you CC the ARM maintainers.
> $ git grep -A5 ARM MAINTAINERS
> MAINTAINERS:ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
> MAINTAINERS-M:  Ian Campbell <ian.campbell@citrix.com>
> MAINTAINERS-M:  Stefano Stabellini <stefano.stabellini@citrix.com>
> MAINTAINERS-M:  Tim Deegan <tim@xen.org>
> MAINTAINERS-S:  Supported
> MAINTAINERS-L:  xen-devel@lists.xen.org
>
>> From: Evgeny Fedotov <e.fedotov@samsung.com>
>>
>> Implement save/restore of hvm context hypercall.
>> In hvm context save/restore, we save gic, timer and vfp registers.
>>
>> Changes from v4: Save vcpu registers within hvm context, and purge
>> the save-vcpu-register patch.
> The inter-version changelog should go after the main commit message and
> the S-o-b separated by a "---" on a line by itself. This way it is not
> included in the final commit.
OK.
> [...]
>> +static int vgic_irq_rank_save(struct vgic_rank *ext,
>> +                               struct vgic_irq_rank *rank)
>> +{
>> +    spin_lock(&rank->lock);
> This is probably wise, but the domain must be paused at this point,
> right?
I think this lock can be removed, thanks.
>
>> +    /* Some of VGIC registers are not used yet, it is for a future usage */
>> +    /* IENABLE, IACTIVE, IPEND,  PENDSGI registers */
>> +    ext->ienable = rank->ienable;
>> +    ext->iactive = rank->iactive;
>> +    ext->ipend = rank->ipend;
>> +    ext->pendsgi = rank->pendsgi;
>> +    /* ICFG */
>> +    ext->icfg[0] = rank->icfg[0];
>> +    ext->icfg[1] = rank->icfg[1];
>> +    /* IPRIORITY */
>> +    if ( sizeof(rank->ipriority) != sizeof (ext->ipriority) )
>> +    {
>> +        dprintk(XENLOG_G_ERR, "hvm_hw_gic: check ipriority dumping space\n");
> What makes ipriority (and itargets below) special enough to warrant such
> a check compared with all the other fields?
>
> Could these checks be BUILD_BUG_ON?
If we use memcpy I think we should always check if the size of source 
and destination is equal.
Of course,  BUILD_BUG_ON is safe so I can  use it. Thanks.
>
>> +        return -EINVAL;
>> +    }
>> +    memcpy(ext->ipriority, rank->ipriority, sizeof(rank->ipriority));
>> +    /* ITARGETS */
>> +    if ( sizeof(rank->itargets) != sizeof (ext->itargets) )
>> +    {
>> +        dprintk(XENLOG_G_ERR, "hvm_hw_gic: check itargets dumping space\n");
>> +        return -EINVAL;
>> +    }
>> +    memcpy(ext->itargets, rank->itargets, sizeof(rank->itargets));
>> +    spin_unlock(&rank->lock);
>> +    return 0;
>> +}
>> +
>> +static int gic_save(struct domain *d, hvm_domain_context_t *h)
>> +{
>> +    struct hvm_hw_gic ctxt;
>> +    struct vcpu *v;
>> +
>> +    /* Save the state of GICs */
>> +    for_each_vcpu( d, v )
> Where is the GICD state saved then?
The only GICD structure we save for guest domain is struct 
vgic_irq_rank, it includes: IENABLE, IACTIVE, IPEND,  PENDSGI, ICFG, 
IPRIORITY, ITARGETS registers. We create the same structure inside hvm : 
vgic_rank (that is no guaranteed to be the same as struct vgic_irq_rank) 
and save it calling vgic_irq_rank_save routine below in gic_save.
>
>> +    {
>> +        ctxt.gic_hcr = v->arch.gic_hcr;
>> +        ctxt.gic_vmcr = v->arch.gic_vmcr;
>> +        ctxt.gic_apr = v->arch.gic_apr;
>> +
>> +        /* Save list registers and masks */
>> +        /* (it is not necessary to save/restore them, but LR state can have
>> +         * influence on downtime after Live Migration (to be tested)
> What does this mean?
>
> I'm in two minds about whether LR counts as architectural state, since
> it is hypervisor side and not guest facing. I'd have thought that the LR
> content could be reconstructed from the pending and active bitmasks.
Well, I tried to save LR to restore all interrupt queues (pending and 
active) in future to minimize the quantity of lost IRQs during the 
migration. But in this stage it is quite wrong to save LR so I remove this.
>
>> +         */
>> +        if ( sizeof(v->arch.gic_lr) > sizeof (ctxt.gic_lr) )
>> +        {
>> +             dprintk(XENLOG_G_ERR, "hvm_hw_gic: increase LR dumping space\n");
>> +             return -EINVAL;
>> +        }
>> +        memcpy(ctxt.gic_lr, v->arch.gic_lr, sizeof(v->arch.gic_lr));
>> +        ctxt.lr_mask = v->arch.lr_mask;
>> +        ctxt.event_mask = v->arch.event_mask;
> These last two in particular make me think that saving the LRs is wrong.
OK
>
>> +        /* Save PPI states (per-CPU) */
>> +        /* It is necessary if SMP enabled */
>> +        if ( vgic_irq_rank_save(&ctxt.ppi_state,  &v->arch.vgic.private_irqs) )
>> +            return 1;
>> +
>> +        if ( hvm_save_entry(GIC, v->vcpu_id, h, &ctxt) != 0 )
>> +            return 1;
>> +    }
>> +    return 0;
>> +}
>> +
>> +static int gic_load(struct domain *d, hvm_domain_context_t *h)
>> +{
>> +    int vcpuid;
>> +    struct hvm_hw_gic ctxt;
>> +    struct vcpu *v;
>> [...]
>> +    return 0;
>> +}
>> +
>> +HVM_REGISTER_SAVE_RESTORE(GIC, gic_save, gic_load, 1, HVMSR_PER_VCPU);
>> +
>> [...]
>> +#ifdef CONFIG_ARM_32
>> +        ctxt.mair0 = v->arch.mair0;
>> +        ctxt.mair1 = v->arch.mair1;
>> +#else
>> +        ctxt.mair0 = v->arch.mair;
>> +#endif
>> +        /* Control Registers */
>> +        ctxt.actlr = v->arch.actlr;
>> +        ctxt.sctlr = v->arch.sctlr;
>> +        ctxt.cpacr = v->arch.cpacr;
>> [...]
>> +        ctxt.x0 = c.x0;
> Would it make sense to include a field of type vcpu_guest_core_regs in
> the save struct instead of this big list?
Yes, I think vcpu_guest_core_regs is already common definition for ARM32 
and ARM64.

  
[...]

>> +        #ifdef CONFIG_ARM_32
> #ifdef in the first columns please.
OK
>
>> +                ctxt.spsr_fiq = c.spsr_fiq;
>> +                ctxt.spsr_irq = c.spsr_irq;
>> +                ctxt.spsr_und = c.spsr_und;
>> +                ctxt.spsr_abt = c.spsr_abt;
> and don't indent these as if they were inside a block
Sure
>
> You had this right when you saved the MAIR registers above.
>
>> +        #endif
>> +        #ifdef CONFIG_ARM_64
> or #else if you prefer.
OK
>
>> +                ctxt.sp_el0 = c.sp_el0;
>> +                ctxt.sp_el1 = c.sp_el1;
>> +                ctxt.elr_el1 = c.elr_el1;
>> +        #endif
>> +
>> +        /* check VFP state size before dumping */
>> +        if ( sizeof(v->arch.vfp) > sizeof (ctxt.vfp) )
>> +        {
>> +            dprintk(XENLOG_G_ERR, "hvm_hw_cpu: increase VFP dumping space\n");
>> +            return -EINVAL;
>> +        }
>> +        memcpy((void*) &ctxt.vfp, (void*) &v->arch.vfp, sizeof(v->arch.vfp));
>> +
>> +        ctxt.pause_flags = v->pause_flags;
> x86 has at the top of the loop:
>          /* We don't need to save state for a vcpu that is down; the restore
>           * code will leave it down if there is nothing saved. */
>          if ( test_bit(_VPF_down, &v->pause_flags) )
>              continue;
>
> which I think is preferable to this.
OK
>
>> diff --git a/xen/include/asm-arm/hvm/support.h b/xen/include/asm-arm/hvm/support.h
>> new file mode 100644
>> index 0000000..8311f2f
>> --- /dev/null
>> +++ b/xen/include/asm-arm/hvm/support.h
>> @@ -0,0 +1,29 @@
>> +/*
>> + * support.h: HVM support routines used by ARMv7 VE.
> Not just on Vexpress nor just on v7 I expect?
VE means Virtualization Extentions here.
OK, we should support ARM v8 in future,so can be "HVM support routines 
used by ARMv7/v8 with Virtualization Extensions" a good comment?
>> + *
>> + * Copyright (c) 2012, Citrix Systems
> Really?
OK
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
>> + * Place - Suite 330, Boston, MA 02111-1307 USA.
>> + */
>> +
>> +#ifndef __ASM_ARM_HVM_SUPPORT_H__
>> +#define __ASM_ARM_HVM_SUPPORT_H__
>> +
>> +#include <xen/types.h>
>> +#include <public/hvm/ioreq.h>
>> +#include <xen/sched.h>
>> +#include <xen/hvm/save.h>
>> +#include <asm/processor.h>
> Just some #includes here?
Yes, I remove unnecessary includes.
>
> Ian,
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

  reply	other threads:[~2013-11-13  8:00 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-08  7:50 [PATCH RESEND v5 0/6] xen/arm: live migration support in arndale board Jaeyong Yoo
2013-11-08  7:50 ` [PATCH RESEND v5 1/6] xen/arm: Implement hvm save and restore Jaeyong Yoo
2013-11-12 15:15   ` Ian Campbell
2013-11-13  8:00     ` Eugene Fedotov [this message]
2013-11-13 10:56       ` Ian Campbell
     [not found]         ` <52836784.8050008@samsung.com>
2013-11-13 12:25           ` Eugene Fedotov
     [not found]           ` <1384343257.5406.86.camel@kazak.uk.xensource.com>
2013-11-13 12:22             ` Ian Campbell
2013-11-13 12:31             ` Eugene Fedotov
2013-11-08  7:50 ` [PATCH RESEND v5 2/6] xen/arm: Implement get_maximum_gpfn hypercall for arm Jaeyong Yoo
2013-11-12 15:21   ` Ian Campbell
2013-11-13  8:28     ` Eugene Fedotov
2013-11-13 10:58       ` Ian Campbell
2013-11-15  7:04         ` Eugene Fedotov
2013-11-19 12:35           ` Eugene Fedotov
2013-11-19 12:53             ` Ian Campbell
2013-11-19 13:09               ` Eugene Fedotov
2013-11-08  7:50 ` [PATCH RESEND v5 3/6] xen/arm: Implement modify_returncode Jaeyong Yoo
2013-11-12 15:24   ` Ian Campbell
2013-11-13  8:40     ` Eugene Fedotov
2013-11-08  7:50 ` [PATCH RESEND v5 4/6] xen/arm: Implement virtual-linear page table for guest p2m mapping in live migration Jaeyong Yoo
2013-11-12 15:58   ` Ian Campbell
2013-11-14 23:58     ` Jaeyong Yoo
2013-11-18  3:47       ` Jaeyong Yoo
2013-11-19 11:42         ` Ian Campbell
2013-11-19 11:37       ` Ian Campbell
2013-11-08  7:50 ` [PATCH RESEND v5 5/6] xen/arm: Implement hypercall for dirty page tracing Jaeyong Yoo
2013-11-12 16:56   ` Ian Campbell
2013-11-15  2:26     ` Jaeyong Yoo
2013-11-19  1:32       ` Jaeyong Yoo
2013-11-19 11:57         ` Ian Campbell
2013-11-20  9:49           ` Jaeyong Yoo
2013-11-20 10:03             ` Ian Campbell
2013-11-19 11:54       ` Ian Campbell
2013-11-15  4:15     ` Jaeyong Yoo
2013-11-19 11:38       ` Ian Campbell
2013-11-08  7:50 ` [PATCH RESEND v5 6/6] xen/arm: Implement toolstack for xl restore/save and migrate Jaeyong Yoo
2013-11-12 17:22   ` Ian Campbell
2013-11-13  9:57     ` Eugene Fedotov
2013-11-13 11:09       ` Ian Campbell
     [not found]         ` <52836DCA.7080206@samsung.com>
     [not found]           ` <1384345148.5406.94.camel@kazak.uk.xensource.com>
2013-11-13 12:21             ` Ian Campbell
2013-11-13 12:25           ` Fwd: " Eugene Fedotov
2013-11-19 11:06         ` Eugene Fedotov
2013-11-19 12:01           ` Ian Campbell
2014-04-01 19:39 ` [PATCH RESEND v5 0/6] xen/arm: live migration support in arndale board Julien Grall
2014-04-02 15:06   ` Wei Huang
2014-04-02 15:21     ` Stefano Stabellini

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=528331A3.8070608@samsung.com \
    --to=e.fedotov@samsung.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=xen-devel@lists.xen.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 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.