All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: stefano.stabellini@eu.citrix.com, ross.philipson@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [QEMU-traditional] ACPI AML code races with QEMU updating the vCPU count when hotplugging more than ~14 VCPUs.
Date: Thu, 9 May 2013 23:50:47 +0200	[thread overview]
Message-ID: <20130509235047.659a5867@thinkpad> (raw)
In-Reply-To: <20130509204723.GA5713@localhost.localdomain>

On Thu, 9 May 2013 16:47:24 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> This is a race so the amount varies but on a 4PCPU box
> I seem to get only ~14 out of 16 vCPUs I want to online.
> 
> The issue at hand is that QEMU xenstore.c hotplug code
> does to the command: xl vcpu-set latest 16
> (guest config has vcpus=1, maxvcpus=32) this:
> 
> 
> QEMU:						Guest OS:
> -xenstore_process_vcpu_set_event
>  -> Gets an XenBus notification for CPU1
>  -> Updates the gpe_state.cpus_state bitfield.       
> 	-> Pulses the ACPI SCI 
> 						- ACPI SCI kicks in
> 
>  -> Gets an XenBus notification for CPU2
>  -> Updates the gpe_state.cpus_state bitfield.
> 	-> Pulses the ACPI SCI 
> 
>  -> Gets an XenBus notification for CPU3
>  -> Updates the gpe_state.cpus_state bitfield.
> 	-> Pulses the ACPI SCI 
>    ...
> 						 - Method(PRST) invoked
> 							  
>  -> Gets an XenBus notification for CPU12
>  -> Updates the gpe_state.cpus_state bitfield.
> 	-> Pulses the ACPI SCI 
> 						  - reads AF00 for CPU state
> 						    [gets 0xff]
> 						  - reads AF02 [gets 0x7f]
> 
> 							
>  -> Gets an XenBus notification for CPU13
>  -> Updates the gpe_state.cpus_state bitfield.
> 	-> Pulses the ACPI SCI 
> 
> 	.. until VCPU 16
> 						 - Method PRST updates
> 						   PR01 through 13 FLG
> 						   entry.
> 						 - PR01->PR13 _MAD
> 						   invoked.
> 
> 						 - Brings up 13 CPUs.
> 
> While QEMU updates the rest of the cpus_state bitfields the ACPI AML
> only does the CPU hotplug on those it had read. For reference
> please see the debug patch and also the QEMU log. Look for
> 'gpe_cpus_readb'.
> 
> My thinking of how to fix this is just to add in
> xenstore_process_vcpu_set_event
>  - a scan for all of the other availability/cpu states.
>  - for each of the cpu availability states query the
>    gpe_state.cpus_state and if different modify them (and set
>    a bool that one of them was modified).
>  - When done scanning and if the bool was set, then kick of the
>    qemu_irq_pulse.
> 
> Then if the other events are triggered we can just check the
> gpe_state.cpus_state against what XenBus thinks and if they
> are the same just return without doing the qemu_irq_pulse.
> 
> Thoughts?
Could you check if switching from level to edge handling in AML helps?
http://git.qemu.org/?p=seabios.git;a=commit;h=9c6635bd48d39a1d17d0a73df6e577ef6bd0037c


-- 
Regards,
  Igor

  reply	other threads:[~2013-05-09 21:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-09 20:47 [QEMU-traditional] ACPI AML code races with QEMU updating the vCPU count when hotplugging more than ~14 VCPUs Konrad Rzeszutek Wilk
2013-05-09 21:50 ` Igor Mammedov [this message]
2013-05-10 15:01   ` Konrad Rzeszutek Wilk
2013-05-10 13:55 ` upstream QEMU and cpu hotplug Was: " Stefano Stabellini
2013-05-10 17:23   ` 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=20130509235047.659a5867@thinkpad \
    --to=imammedo@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=ross.philipson@citrix.com \
    --cc=stefano.stabellini@eu.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.