xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Tim Deegan <Tim.Deegan@eu.citrix.com>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	"Zhang, Jianwu" <jianwu.zhang@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Xu, Jiajun" <jiajun.xu@intel.com>
Subject: Re: [PATCH] v2 (Re: cs:21768 causes guest spend more time on boot up)
Date: Tue, 20 Jul 2010 12:16:46 +0100	[thread overview]
Message-ID: <C86B442E.1B0D8%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <20100720103859.GN13291@whitby.uk.xensource.com>

Ah, this is because you poll the ring and never actually use let alone clear
the event channel rx port? This looks like a good fix, thanks.

 -- Keir

On 20/07/2010 11:38, "Tim Deegan" <Tim.Deegan@eu.citrix.com> wrote:

> Here's another patch that also unsticks CentOS 5.5 boot for me, and
> seems safer and saner (even if it turns out that the bug is somewhere
> else and I'm just perturbing the inputs to some more complex system...)
> 
> Cheers,
> 
> Tim.
> 
> hvmloader: clear the xenbus event-channel when we're done with it.
> Otherwise a later xenbus client that naively waits for the rising edge
> could get stuck.
> 
> Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
> 
> diff -r c4a83e3cc6b4 tools/firmware/hvmloader/util.c
> --- a/tools/firmware/hvmloader/util.c Thu Jul 15 18:18:16 2010 +0100
> +++ b/tools/firmware/hvmloader/util.c Tue Jul 20 11:34:06 2010 +0100
> @@ -587,10 +587,28 @@
>      return table;
>  }
>  
> +struct shared_info *get_shared_info(void)
> +{
> +    static struct shared_info *shared_info = NULL;
> +    struct xen_add_to_physmap xatp;
> +
> +    if ( shared_info == NULL )
> +    {
> +        /* Map shared-info page. */
> +        xatp.domid = DOMID_SELF;
> +        xatp.space = XENMAPSPACE_shared_info;
> +        xatp.idx   = 0;
> +        xatp.gpfn  = 0xfffff;
> +        if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
> +            BUG();
> +        shared_info = (struct shared_info *) (xatp.gpfn << 12);
> +    }
> +    return shared_info;
> +}
> +
>  uint16_t get_cpu_mhz(void)
>  {
> -    struct xen_add_to_physmap xatp;
> -    struct shared_info *shared_info = (struct shared_info *)0xfffff000;
> +    struct shared_info *shared_info = get_shared_info();
>      struct vcpu_time_info *info = &shared_info->vcpu_info[0].time;
>      uint64_t cpu_khz;
>      uint32_t tsc_to_nsec_mul, version;
> @@ -599,14 +617,6 @@
>      static uint16_t cpu_mhz;
>      if ( cpu_mhz != 0 )
>          return cpu_mhz;
> -
> -    /* Map shared-info page. */
> -    xatp.domid = DOMID_SELF;
> -    xatp.space = XENMAPSPACE_shared_info;
> -    xatp.idx   = 0;
> -    xatp.gpfn  = (unsigned long)shared_info >> 12;
> -    if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
> -        BUG();
>  
>      /* Get a consistent snapshot of scale factor (multiplier and shift). */
>      do {
> diff -r c4a83e3cc6b4 tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h Thu Jul 15 18:18:16 2010 +0100
> +++ b/tools/firmware/hvmloader/util.h Tue Jul 20 11:34:06 2010 +0100
> @@ -68,6 +68,9 @@
>  #define pci_writeb(devfn, reg, val) (pci_write(devfn, reg, 1, (uint8_t) val))
>  #define pci_writew(devfn, reg, val) (pci_write(devfn, reg, 2, (uint16_t)val))
>  #define pci_writel(devfn, reg, val) (pci_write(devfn, reg, 4, (uint32_t)val))
> +
> +/* Get a pointer to the shared-info page */
> +struct shared_info *get_shared_info(void);
>  
>  /* Get CPU speed in MHz. */
>  uint16_t get_cpu_mhz(void);
> diff -r c4a83e3cc6b4 tools/firmware/hvmloader/xenbus.c
> --- a/tools/firmware/hvmloader/xenbus.c Thu Jul 15 18:18:16 2010 +0100
> +++ b/tools/firmware/hvmloader/xenbus.c Tue Jul 20 11:34:06 2010 +0100
> @@ -53,14 +53,20 @@
>             (unsigned long) rings, (unsigned long) event);
>  }
>  
> -/* Reset the xenbus connection so the next kernel can start again.
> - * We zero out the whole ring -- the backend can handle this, and it's
> - * not going to surprise any frontends since it's equivalent to never
> - * having used the rings. */
> +/* Reset the xenbus connection so the next kernel can start again. */
>  void xenbus_shutdown(void)
>  {
>      ASSERT(rings != NULL);
> +
> +    /* We zero out the whole ring -- the backend can handle this, and it's
> +     * not going to surprise any frontends since it's equivalent to never
> +     * having used the rings. */
>      memset(rings, 0, sizeof *rings);
> +
> +    /* Clear the xenbus event-channel too */
> +    get_shared_info()->evtchn_pending[event / sizeof (unsigned long)]
> +        &= ~(1UL << ((event % sizeof (unsigned long))));
> +
>      rings = NULL;
>  }
>  

  reply	other threads:[~2010-07-20 11:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-15  8:07 cs:21768 causes guest spend more time on boot up Zhang, Yang Z
2010-07-15  9:48 ` Tim Deegan
2010-07-15 12:22   ` Tim Deegan
2010-07-15 15:14     ` Zhang, Yang Z
2010-07-15 15:20       ` Tim Deegan
2010-07-15 15:30         ` Zhang, Yang Z
2010-07-15 15:33           ` Tim Deegan
2010-07-19 10:55             ` [PATCH] " Tim Deegan
2010-07-19 11:46               ` Keir Fraser
2010-07-19 12:19                 ` Tim Deegan
2010-07-19 12:24                   ` Keir Fraser
2010-07-19 12:30                     ` Keir Fraser
2010-07-20 10:38                   ` [PATCH] v2 (Re: cs:21768 causes guest spend more time on boot up) Tim Deegan
2010-07-20 11:16                     ` Keir Fraser [this message]
2010-07-22  9:01                       ` Zhang, Jianwu
2010-07-22 13:20                         ` Keir Fraser
2010-07-22 13:41                           ` Tim Deegan

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=C86B442E.1B0D8%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=Tim.Deegan@eu.citrix.com \
    --cc=jiajun.xu@intel.com \
    --cc=jianwu.zhang@intel.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=yang.z.zhang@intel.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 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).