Re: cpu hotplug
On Mon, Sep 20, 2010 at 09:07:16PM -0400, Kevin O'Connor wrote: On Mon, Sep 20, 2010 at 08:50:17AM +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 06:03:31PM -0400, Kevin O'Connor wrote: I was wrong. The cpu_set x offline does send an event to the guest OS. SeaBIOS even forwards the event along - as far as I can tell a Notify(CPxx, 3) event is generated by SeaBIOS. My Windows 7 ultimate beta seems to receive the event okay (it pops up a dialog box which says you can't unplug cpus). It may react to Eject() method. The eject method is called by the OS to notify the host. Right now SeaBIOS's eject method doesn't do anything. Yes. What I meant is it may react on presence of Eject() method. In my experience Windows consider all devices with Eject() method as hot-pluggable. But actually IIRC Windows 7 gave me this dialog box with BOCHS BIOS too and there we didn't have Eject() method. Unfortunately, my test linux guest OS (FC13) doesn't seem to do anything with the unplug Notify event. I've tried with the original FC13 and with a fully updated version - no luck. So, I'm guessing this has something to do with the guest OS. Can you verify that _STA() return zero after cpu unplug? I've verified that. I've also verified that Linux doesn't call the _STA method after Notify(CPxx, 3). It does call _STA on startup and after a Notify(CPxx, 1) event. So, the Linux kernel in my FC13 guest just seems to be ignoring Notify(3) events. (According to ACPI spec, the guest should shutdown the cpu and then call the eject method.) In older kernels _STA was called on Notify(3), but recently cpu hot-plug in Linux was changed. Can you check what happens if you'll call Notify(1) on unplug? Spec says that the value is: Device Check. Used to notify OSPM that the device either appeared or disappeared. so may be it should be called on hot-plug and hot-unplug. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 05:57:25PM -0400, Kevin O'Connor wrote:
On Sun, Sep 19, 2010 at 06:24:33PM +0200, Conrad Wood wrote:
a script with my exact steps is below. Result is reproducible.
[...]
echo Ejecting CPU #4
echo cpu_set 4 offline | nc ${MONITORHOST} ${MONITORPORT} /dev/null
printInfo
echo Setting all available cpus to online...
ssh -lroot ${VM} find /sys/devices/system/cpu/ -type f -path
'*/cpu?/online' -exec bash -c \echo 1 {}\ \;
It's not clear if you can trust your guests or not. If you can trust
the guest OS, it should be safe to run:
echo 1 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:xx/eject
in the guest. A normal linux guest wont reactivate the cpu after
that.
You can trust you guest more then you can trust a users of your guest.
It is easy for a user to do echo, it is much harder to modify guest to not
remove /sys entry for un-plugged cpu.
But I agree that kvm shouldn't allow to reactivate un-plugged cpu even
if it is not destroy it on un-plug.
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 06:03:31PM -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 06:12:14PM +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 12:04:51PM -0400, Kevin O'Connor wrote: I'm confused. The cpu_set x offline doesn't appear to do anything for me. It does not disable the cpu, nor does it inform the guest to disable the cpu. [...] Then cpu eject method in seabios has a bug. When cpu_set x offline is called qemu sets status bit in gpe and injects ACPI interrupt. ACPI should do Notify() on cpu object when it happens. I was wrong. The cpu_set x offline does send an event to the guest OS. SeaBIOS even forwards the event along - as far as I can tell a Notify(CPxx, 3) event is generated by SeaBIOS. My Windows 7 ultimate beta seems to receive the event okay (it pops up a dialog box which says you can't unplug cpus). It may react to Eject() method. Unfortunately, my test linux guest OS (FC13) doesn't seem to do anything with the unplug Notify event. I've tried with the original FC13 and with a fully updated version - no luck. So, I'm guessing this has something to do with the guest OS. Can you verify that _STA() return zero after cpu unplug? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Mon, Sep 20, 2010 at 08:50:17AM +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 06:03:31PM -0400, Kevin O'Connor wrote: I was wrong. The cpu_set x offline does send an event to the guest OS. SeaBIOS even forwards the event along - as far as I can tell a Notify(CPxx, 3) event is generated by SeaBIOS. My Windows 7 ultimate beta seems to receive the event okay (it pops up a dialog box which says you can't unplug cpus). It may react to Eject() method. The eject method is called by the OS to notify the host. Right now SeaBIOS's eject method doesn't do anything. Unfortunately, my test linux guest OS (FC13) doesn't seem to do anything with the unplug Notify event. I've tried with the original FC13 and with a fully updated version - no luck. So, I'm guessing this has something to do with the guest OS. Can you verify that _STA() return zero after cpu unplug? I've verified that. I've also verified that Linux doesn't call the _STA method after Notify(CPxx, 3). It does call _STA on startup and after a Notify(CPxx, 1) event. So, the Linux kernel in my FC13 guest just seems to be ignoring Notify(3) events. (According to ACPI spec, the guest should shutdown the cpu and then call the eject method.) -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote:
On Sat, 2010-09-18 at 10:32 -0400, Kevin O'Connor wrote:
On Fri, Sep 17, 2010 at 11:39:36PM +0200, Conrad Wood wrote:
Hi everyone,
I'm currently looking into hotplugging CPUs.
This exclusively with linux-guests and linux-host.
I have found some (conflicting) information about this on the net.
As far as I read:
* seabios doesn't support SMP (but why does the linux-guest show
multiple cpus?)
* there is no uniform way of informing the linux kernel that a cpu has
added (Found references to a unisys way of doing it though, which seems
to be still implemented)
* the kernel needs the acpi tables to determine how many cpus it has,
thus the support in the bios would involve an aml-compiler to
hot-compile new acpi tables.
SeaBIOS version 0.6.1 has ACPI support for cpu-hotplug. It's been
tested on Linux and Windows. Search the mail archive for cpu
hotplug for the details.
-Kevin
hm... after upgrading to seabios 0.6.1 and qemu-kvm 0.13.50 (git today)
I get:
qemu-kvm/hw/qdev.c:94: qdev_create_from_info: Assertion
`bus-allow_hotplug' failed.
when I issue cpu_set 4 online on the cmd line. ;(
starting with commandline:
/usr/local/kvm/bin/qemu-system-x86_64 -M pc \
-bios /usr/local/kvm/seabios/latest \
-cpu phenom -enable-kvm -m 1024 -smp 4,cores=2,maxcpus=30,threads=1
-name testapp -uuid 5ee3d553-f6a4-0f33-6823-ee16a16a7fb4 -nodefaults \
-numa 2 \
-monitor telnet:localhost:9401,server,nowait -rtc base=utc -boot
${BOOTSTRAP} -device
rtl8139,vlan=0,id=net0,mac=52:54:01:65:e6:70,bus=pci.0,addr=0x4 \
-net tap,ifname=cnw0 -chardev pty,id=serial0 -device
isa-serial,chardev=serial0 -k en-gb -vga cirrus \
-drive
file=/srv/kvm/test-app.qcow2,if=virtio,cache=writeback,bus=0,id=a0,index=0,media=disk,format=qcow2,serial=1,boot=on,snapshot=${SNAPSHOT}
\
-nodefaults \
-${WD} \
--enable-nesting \
any ideas ?
Known problem in qemu. There was a patch for this, but qemu maintainers
think it is not good enough.
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 08:38 +0200, Gleb Natapov wrote: On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote: On Sat, 2010-09-18 at 10:32 -0400, Kevin O'Connor wrote: On Fri, Sep 17, 2010 at 11:39:36PM +0200, Conrad Wood wrote: Hi everyone, I'm currently looking into hotplugging CPUs. This exclusively with linux-guests and linux-host. I have found some (conflicting) information about this on the net. [...] Well, I got a bit further - thanks so far for your help. Given 1. kvm-72 2. linux-guest-kernel 2.6.35.4 3. kernel cmdline maxcpus=32 possible_cpus=32 I can set cpu_set 5 online in the monitor and get indeed a new cpu appearing in /sys/devices..., which I can then set online in the guest by doing echo 1 /sys/devices/.../online. /proc/cpuinfo in the guest then reports the new cpu. But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? echo 1 /sys/devices.../online makes no difference to what info cpus reports, even though the guests /proc/cpuinfo shows expected behaviour. Sorry to bother everyone, just trying to understand this. How, if at all, are the guests' cpus mapped to physical cpus or cores on the host? Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 12:41:37PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 08:38 +0200, Gleb Natapov wrote: On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote: On Sat, 2010-09-18 at 10:32 -0400, Kevin O'Connor wrote: On Fri, Sep 17, 2010 at 11:39:36PM +0200, Conrad Wood wrote: Hi everyone, I'm currently looking into hotplugging CPUs. This exclusively with linux-guests and linux-host. I have found some (conflicting) information about this on the net. [...] Well, I got a bit further - thanks so far for your help. Given 1. kvm-72 2. linux-guest-kernel 2.6.35.4 3. kernel cmdline maxcpus=32 possible_cpus=32 I can set cpu_set 5 online in the monitor and get indeed a new cpu appearing in /sys/devices..., which I can then set online in the guest by doing echo 1 /sys/devices/.../online. /proc/cpuinfo in the guest then reports the new cpu. But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? Because they are halted? Run multiple cpu hogs in the guest and see if cpus will still be halted as reported by monitor. Also kvm-72 is so ancient that I am not sure it reports cpu state correctly in monitor at all. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote: [...] But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? Because they are halted? Run multiple cpu hogs in the guest and see if cpus will still be halted as reported by monitor. Also kvm-72 is so ancient that I am not sure it reports cpu state correctly in monitor at all. -- fair enough, upgraded to 0.12.5, same results. tried a cpu-hog (small loop forking 5 times and each fork doing some integer arithmetics for a while) - no change in info cpus thank you, but I still don't get it ;-) Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote: [...] But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? Because they are halted? Run multiple cpu hogs in the guest and see if cpus will still be halted as reported by monitor. Also kvm-72 is so ancient that I am not sure it reports cpu state correctly in monitor at all. -- fair enough, upgraded to 0.12.5, same results. tried a cpu-hog (small loop forking 5 times and each fork doing some integer arithmetics for a while) - no change in info cpus thank you, but I still don't get it ;-) At what rip are they halted? Try to run without kvm and see if the result is the same. Can you provide output of info cpus here? Are you using qemu-kvm or qemu BTW? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote: [...] But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? Because they are halted? Run multiple cpu hogs in the guest and see if cpus will still be halted as reported by monitor. Also kvm-72 is so ancient that I am not sure it reports cpu state correctly in monitor at all. -- fair enough, upgraded to 0.12.5, same results. tried a cpu-hog (small loop forking 5 times and each fork doing some integer arithmetics for a while) - no change in info cpus thank you, but I still don't get it ;-) At what rip are they halted? Try to run without kvm and see if the result is the same. Can you provide output of info cpus here? Are you using qemu-kvm or qemu BTW? I am using qemu-kvm (debian package Version: 0.12.5+dfsg-3). Here's the info cpus with and without kvm acceleration. basically qemu shows the behavior I'd expect, kvm does not. Or do I misunderstand something? I wonder. if this is relevant: The host only has a single cpu, with 4 cores, I had expected those to be seen as cpus in the guest, similar how linux lists each core as a cpu in the host. kvm -no-kvm: after guest has booted: (qemu) info cpus * CPU #0: pc=0x81047730 (halted) thread_id=17121 CPU #1: pc=0x81047730 (halted) thread_id=17121 CPU #2: pc=0x81047730 (halted) thread_id=17121 CPU #3: pc=0x81047730 (halted) thread_id=17121 running cpuhog with 5 forks: (qemu) info cpus * CPU #0: pc=0x00400698 thread_id=17121 CPU #1: pc=0x00400698 thread_id=17121 CPU #2: pc=0x00400698 thread_id=17121 CPU #3: pc=0x00400698 thread_id=17121 kvm -enable-kvm after guest has booted: (qemu) info cpus * CPU #0: pc=0x81047730 thread_id=27082 CPU #1: pc=0x81047730 (halted) thread_id=27083 CPU #2: pc=0x81047730 (halted) thread_id=27084 CPU #3: pc=0x81047730 (halted) thread_id=27085 running cpuhog with 5 forks: (qemu) info cpus * CPU #0: pc=0x004006b6 thread_id=27082 CPU #1: pc=0x004006b6 (halted) thread_id=27083 CPU #2: pc=0x004006b6 (halted) thread_id=27084 CPU #3: pc=0x004006b6 (halted) thread_id=27085 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 01:32:28PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote: [...] But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? Because they are halted? Run multiple cpu hogs in the guest and see if cpus will still be halted as reported by monitor. Also kvm-72 is so ancient that I am not sure it reports cpu state correctly in monitor at all. -- fair enough, upgraded to 0.12.5, same results. tried a cpu-hog (small loop forking 5 times and each fork doing some integer arithmetics for a while) - no change in info cpus thank you, but I still don't get it ;-) At what rip are they halted? Try to run without kvm and see if the result is the same. Can you provide output of info cpus here? Are you using qemu-kvm or qemu BTW? I am using qemu-kvm (debian package Version: 0.12.5+dfsg-3). Here's the info cpus with and without kvm acceleration. basically qemu shows the behavior I'd expect, kvm does not. Or do I misunderstand something? No you are not. So your qemu-kvm version has cpu state reporting bug too. It is not serious bug, just annoying. pc shows that otherwise everything is working as expected. I wonder. if this is relevant: The host only has a single cpu, with 4 cores, I had expected those to be seen as cpus in the guest, similar how linux lists each core as a cpu in the host. Guest and host has different cpu topology. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 13:39 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:32:28PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote: [...] But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? Because they are halted? Run multiple cpu hogs in the guest and see if cpus will still be halted as reported by monitor. Also kvm-72 is so ancient that I am not sure it reports cpu state correctly in monitor at all. -- fair enough, upgraded to 0.12.5, same results. tried a cpu-hog (small loop forking 5 times and each fork doing some integer arithmetics for a while) - no change in info cpus thank you, but I still don't get it ;-) At what rip are they halted? Try to run without kvm and see if the result is the same. Can you provide output of info cpus here? Are you using qemu-kvm or qemu BTW? I am using qemu-kvm (debian package Version: 0.12.5+dfsg-3). Here's the info cpus with and without kvm acceleration. basically qemu shows the behavior I'd expect, kvm does not. Or do I misunderstand something? No you are not. So your qemu-kvm version has cpu state reporting bug too. It is not serious bug, just annoying. pc shows that otherwise everything is working as expected. I see. Is that a known bug, is someone working on that already? If not... could you point me to the relevant code sections/docs where I can fix that? It actually is quite relevant for me, as I have to manage quite a lot of VMs and need to be able to query how many cpus/cores they're using ;( -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 01:51:29PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 13:39 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:32:28PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote: [...] But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? Because they are halted? Run multiple cpu hogs in the guest and see if cpus will still be halted as reported by monitor. Also kvm-72 is so ancient that I am not sure it reports cpu state correctly in monitor at all. -- fair enough, upgraded to 0.12.5, same results. tried a cpu-hog (small loop forking 5 times and each fork doing some integer arithmetics for a while) - no change in info cpus thank you, but I still don't get it ;-) At what rip are they halted? Try to run without kvm and see if the result is the same. Can you provide output of info cpus here? Are you using qemu-kvm or qemu BTW? I am using qemu-kvm (debian package Version: 0.12.5+dfsg-3). Here's the info cpus with and without kvm acceleration. basically qemu shows the behavior I'd expect, kvm does not. Or do I misunderstand something? No you are not. So your qemu-kvm version has cpu state reporting bug too. It is not serious bug, just annoying. pc shows that otherwise everything is working as expected. I see. Is that a known bug, is someone working on that already? If not... could you point me to the relevant code sections/docs where I can fix that? It actually is quite relevant for me, as I have to manage quite a lot of VMs and need to be able to query how many cpus/cores they're using ;( I fixed it several times in the past[0][1][3], but it keeps re-appearing :) I hope current qemu-kvm head is OK. [0] 865aa3fec2b3d83c9b6edd452050a30ef6eaf3b8 [1] 8c7d4cb7163d1c97df4439e2e0edb5918abf106b [2] d6d233543d543fcf34df6190bbce5daf38d870f5 -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 13:59 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:51:29PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 13:39 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:32:28PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 13:13 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 01:09:39PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 12:46 +0200, Gleb Natapov wrote: [...] But... why does the command info cpus in the monitor report all cpus apart from CPU0 as (halted) ? Because they are halted? Run multiple cpu hogs in the guest and see if cpus will still be halted as reported by monitor. Also kvm-72 is so ancient that I am not sure it reports cpu state correctly in monitor at all. -- fair enough, upgraded to 0.12.5, same results. tried a cpu-hog (small loop forking 5 times and each fork doing some integer arithmetics for a while) - no change in info cpus thank you, but I still don't get it ;-) At what rip are they halted? Try to run without kvm and see if the result is the same. Can you provide output of info cpus here? Are you using qemu-kvm or qemu BTW? I am using qemu-kvm (debian package Version: 0.12.5+dfsg-3). Here's the info cpus with and without kvm acceleration. basically qemu shows the behavior I'd expect, kvm does not. Or do I misunderstand something? No you are not. So your qemu-kvm version has cpu state reporting bug too. It is not serious bug, just annoying. pc shows that otherwise everything is working as expected. I see. Is that a known bug, is someone working on that already? If not... could you point me to the relevant code sections/docs where I can fix that? It actually is quite relevant for me, as I have to manage quite a lot of VMs and need to be able to query how many cpus/cores they're using ;( I fixed it several times in the past[0][1][3], but it keeps re-appearing :) I hope current qemu-kvm head is OK. [0] 865aa3fec2b3d83c9b6edd452050a30ef6eaf3b8 [1] 8c7d4cb7163d1c97df4439e2e0edb5918abf106b [2] d6d233543d543fcf34df6190bbce5daf38d870f5 got it. I'll keep an eye on head and once cpu-hotplug works with head I'll test the state reporting ;) Thank you!!! Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote: On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote: hm... after upgrading to seabios 0.6.1 and qemu-kvm 0.13.50 (git today) I get: [...] any ideas ? Known problem in qemu. There was a patch for this, but qemu maintainers think it is not good enough. Old versions of kvm do work - for example, qemu-kvm-0.12.5 works for me. -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote: On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote: hm... after upgrading to seabios 0.6.1 and qemu-kvm 0.13.50 (git today) I get: [...] any ideas ? Known problem in qemu. There was a patch for this, but qemu maintainers think it is not good enough. Old versions of kvm do work - for example, qemu-kvm-0.12.5 works for me. -Kevin hm... that's the version I am using und it does not work here ;( the hotplug itself seems to work but they're reported as halted. Could you confirm that the cpus in the monitor as reported by info cpus are not reported as (halted) ? Then it seems to be a local misconfiguration. (with -enable-kvm on amd) Thanks! Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 03:29:35PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote: On Sat, Sep 18, 2010 at 08:27:54PM +0200, Conrad Wood wrote: hm... after upgrading to seabios 0.6.1 and qemu-kvm 0.13.50 (git today) I get: [...] any ideas ? Known problem in qemu. There was a patch for this, but qemu maintainers think it is not good enough. Old versions of kvm do work - for example, qemu-kvm-0.12.5 works for me. -Kevin hm... that's the version I am using und it does not work here ;( the hotplug itself seems to work but they're reported as halted. I told you this is cosmetic. They are working. Could you confirm that the cpus in the monitor as reported by info cpus are not reported as (halted) ? Then it seems to be a local misconfiguration. (with -enable-kvm on amd) Thanks! Conrad -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
hm... that's the version I am using und it does not work here ;( the hotplug itself seems to work but they're reported as halted. I told you this is cosmetic. They are working. I agree, the hotplug itself seems to be working! Then it seems to be a local misconfiguration. and if so, I would like to know what I have misconfigured. ;-) and what I can do to persuade this version to provide me with information about which cpus are online and offline. Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 03:29:35PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote: Known problem in qemu. There was a patch for this, but qemu maintainers think it is not good enough. Old versions of kvm do work - for example, qemu-kvm-0.12.5 works for me. hm... that's the version I am using und it does not work here ;( the hotplug itself seems to work but they're reported as halted. Could you confirm that the cpus in the monitor as reported by info cpus are not reported as (halted) ? I sent my email before I saw that you and Gleb had continued the thread. It works in the sense that if I run two cpu hogs in a guest with one cpu I use only one host cpu used. When I turn on an additional guest cpu, I see two host cpus being used. But otherwise, info cpus does seem inaccurate. -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 09:38 -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 03:29:35PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 09:26 -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 08:38:12AM +0200, Gleb Natapov wrote: Known problem in qemu. There was a patch for this, but qemu maintainers think it is not good enough. Old versions of kvm do work - for example, qemu-kvm-0.12.5 works for me. hm... that's the version I am using und it does not work here ;( the hotplug itself seems to work but they're reported as halted. Could you confirm that the cpus in the monitor as reported by info cpus are not reported as (halted) ? I sent my email before I saw that you and Gleb had continued the thread. It works in the sense that if I run two cpu hogs in a guest with one cpu I use only one host cpu used. When I turn on an additional guest cpu, I see two host cpus being used. But otherwise, info cpus does seem inaccurate. -Kevin thanks for confirming that. got a little puzzled there. Cheers, Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 03:35:47PM +0200, Conrad Wood wrote: hm... that's the version I am using und it does not work here ;( the hotplug itself seems to work but they're reported as halted. I told you this is cosmetic. They are working. I agree, the hotplug itself seems to be working! So why are you saying I am using und it does not work here above? Then it seems to be a local misconfiguration. and if so, I would like to know what I have misconfigured. ;-) and what I can do to persuade this version to provide me with information about which cpus are online and offline. halted state is not the way to check for whether cpu is online or offline. cpu may be online but executing hlt instruction so its state will be halted, but cpu itself is online. Actually with kvm today you are not able to check that cpu is offline if it was ever online. Query a guest for cpu status. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote: halted state is not the way to check for whether cpu is online or offline. cpu may be online but executing hlt instruction so its state will be halted, but cpu itself is online. Actually with kvm today you are not able to check that cpu is offline if it was ever online. Query a guest for cpu status. In that regard, info cpus does seem to work - as it only shows me the cpus that have ever been online. Ejecting a cpu in the guest does not remove it from info cpus, but then, I don't think kvm does remove it from being available after an eject. -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 09:46:21AM -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote: halted state is not the way to check for whether cpu is online or offline. cpu may be online but executing hlt instruction so its state will be halted, but cpu itself is online. Actually with kvm today you are not able to check that cpu is offline if it was ever online. Query a guest for cpu status. In that regard, info cpus does seem to work - as it only shows me the cpus that have ever been online. Ejecting a cpu in the guest does not remove it from info cpus, but then, I don't think kvm does remove it from being available after an eject. Exactly. That what I meant by Actually with kvm today you are not able to check that cpu is offline if it was ever online. So if cpu was never online it is easy to check that it is offline (it will not be reported by info cpus). But if it was inserted and then ejected it will still be present in info cpus, but not used by a guest OS. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 15:50 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 09:46:21AM -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote: halted state is not the way to check for whether cpu is online or offline. cpu may be online but executing hlt instruction so its state will be halted, but cpu itself is online. Actually with kvm today you are not able to check that cpu is offline if it was ever online. Query a guest for cpu status. In that regard, info cpus does seem to work - as it only shows me the cpus that have ever been online. Ejecting a cpu in the guest does not remove it from info cpus, but then, I don't think kvm does remove it from being available after an eject. Exactly. That what I meant by Actually with kvm today you are not able to check that cpu is offline if it was ever online. So if cpu was never online it is easy to check that it is offline (it will not be reported by info cpus). But if it was inserted and then ejected it will still be present in info cpus, but not used by a guest OS. -- Gleb. 1) Thanks for clarifying online vs halted - that makes sense and is probably part of what confused me. I need to get the online/offline status of cpus, not if they are halted or not. I understand this is currently not possible with kvm. As I have no direct control over the guest OS, I do however need a solution on the host. Any clues how this could be implemented would be much appreciated. This is important to me. 2) In my case, the cpus are ALWAYS reported as halted, regardless of the current state in the guest. After the guest booted, The cpu infos displays precisely the amount of cpus as initially set by the -smp parameter of kvm. (as halted). any additional cpus added later will be displayed, also as halted - again regardless whether or not the guest switches or had switched them to online. It is reported as halted even whilst the guest is running a cpu-hogger which would stop the cpu from halting. I don't mind so much about this cosmetic display problem ;) Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 04:07:50PM +0200, Conrad Wood wrote: 1) Thanks for clarifying online vs halted - that makes sense and is probably part of what confused me. I need to get the online/offline status of cpus, not if they are halted or not. I understand this is currently not possible with kvm. As I have no direct control over the guest OS, I do however need a solution on the host. Any clues how this could be implemented would be much appreciated. This is important to me. I thought I read somewhere that kvm does not currently support taking a cpu offline - the guest can only voluntarily stop using a cpu. (Gleb would know better, but I think he was trying to say the same thing.) 2) In my case, the cpus are ALWAYS reported as halted, regardless of the current state in the guest. After the guest booted, The cpu infos displays precisely the amount of cpus as initially set by the -smp parameter of kvm. (as halted). any additional cpus added later will be displayed, also as halted - again regardless whether or not the guest switches or had switched them to online. It is reported as halted even whilst the guest is running a cpu-hogger which would stop the cpu from halting. I don't mind so much about this cosmetic display problem ;) I suppose one could check the host cpu usage of the thread reported in info cpus. -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 04:07:50PM +0200, Conrad Wood wrote: On Sun, 2010-09-19 at 15:50 +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 09:46:21AM -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 03:40:45PM +0200, Gleb Natapov wrote: halted state is not the way to check for whether cpu is online or offline. cpu may be online but executing hlt instruction so its state will be halted, but cpu itself is online. Actually with kvm today you are not able to check that cpu is offline if it was ever online. Query a guest for cpu status. In that regard, info cpus does seem to work - as it only shows me the cpus that have ever been online. Ejecting a cpu in the guest does not remove it from info cpus, but then, I don't think kvm does remove it from being available after an eject. Exactly. That what I meant by Actually with kvm today you are not able to check that cpu is offline if it was ever online. So if cpu was never online it is easy to check that it is offline (it will not be reported by info cpus). But if it was inserted and then ejected it will still be present in info cpus, but not used by a guest OS. -- Gleb. 1) Thanks for clarifying online vs halted - that makes sense and is probably part of what confused me. I need to get the online/offline status of cpus, not if they are halted or not. I understand this is currently not possible with kvm. As I have no direct control over the guest OS, I do however need a solution on the host. Any clues how this could be implemented would be much appreciated. This is important to me. Lets establish some terminology to understand each other better: Lets use CPU inserted/ejected to refer to cpu being available/not available to a guest. Lest use CPU online/offline to refer to cpu been used by a guest OS. CPU hot-plug works like this: cpu is inserted (plugged into cpu socket on MB) guest OS is notifies through ACPI guest OS starts to use newly added CPU (makes it online) CPU hot-unplug works like this: guest OS is notifies through ACPI that cpu is going to be removed guest OS stops to use cpu (makes it offline) cpu is ejected (removed from a socket on MB) (kvm never does that part) So which part do you want to know about from a host? You can't really know from a host if cpu is used by guest OS (if it is online/offline in s guest in our terminology) inserted/ejected is management action (it can't be initiated by a guest), so you can keep track of it by yourself. KVM doesn't do it for you right now. More precisely it does, but doesn't have a way to quire it. 2) In my case, the cpus are ALWAYS reported as halted, regardless of the current state in the guest. This is cosmetic but. It does not affect any operation. After the guest booted, The cpu infos displays precisely the amount of cpus as initially set by the -smp parameter of kvm. (as halted). any additional cpus added later will be displayed, also as halted - again regardless whether or not the guest switches or had switched them to online. It is reported as halted even whilst the guest is running a cpu-hogger which would stop the cpu from halting. I don't mind so much about this cosmetic display problem ;) Rightly so since even when it works information it displays is already outdated at the moment you see it anyway. It is useful for debugging, thus I keep fixing it when it breaks. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
[..] Lets establish some terminology to understand each other better: Lets use CPU inserted/ejected to refer to cpu being available/not available to a guest. Lest use CPU online/offline to refer to cpu been used by a guest OS. CPU hot-plug works like this: cpu is inserted (plugged into cpu socket on MB) guest OS is notifies through ACPI guest OS starts to use newly added CPU (makes it online) CPU hot-unplug works like this: guest OS is notifies through ACPI that cpu is going to be removed guest OS stops to use cpu (makes it offline) cpu is ejected (removed from a socket on MB) (kvm never does that part) So which part do you want to know about from a host? You can't really know from a host if cpu is used by guest OS (if it is online/offline in s guest in our terminology) inserted/ejected is management action (it can't be initiated by a guest), so you can keep track of it by yourself. KVM doesn't do it for you right now. More precisely it does, but doesn't have a way to quire it. I need to know if a cpu is currently inserted or ejected. I gather a cpu which is currently inserted, may potentially be used by a guest os. (Wether he actually uses a cpu, puts it online or offline, isn't my concern). The amount of time and number of cpus available to a guest is what I like to keep track of. Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 05:16:24PM +0200, Conrad Wood wrote: [..] Lets establish some terminology to understand each other better: Lets use CPU inserted/ejected to refer to cpu being available/not available to a guest. Lest use CPU online/offline to refer to cpu been used by a guest OS. CPU hot-plug works like this: cpu is inserted (plugged into cpu socket on MB) guest OS is notifies through ACPI guest OS starts to use newly added CPU (makes it online) CPU hot-unplug works like this: guest OS is notifies through ACPI that cpu is going to be removed guest OS stops to use cpu (makes it offline) cpu is ejected (removed from a socket on MB) (kvm never does that part) So which part do you want to know about from a host? You can't really know from a host if cpu is used by guest OS (if it is online/offline in s guest in our terminology) inserted/ejected is management action (it can't be initiated by a guest), so you can keep track of it by yourself. KVM doesn't do it for you right now. More precisely it does, but doesn't have a way to quire it. I need to know if a cpu is currently inserted or ejected. The only way to do that currently is to track it in your management app. I gather a cpu which is currently inserted, may potentially be used by a guest os. (Wether he actually uses a cpu, puts it online or offline, isn't my concern). The amount of time and number of cpus available to a guest is what I like to keep track of. Conrad -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On 09/19/2010 01:59 PM, Gleb Natapov wrote: I fixed it several times in the past[0][1][3], but it keeps re-appearing :) I hope current qemu-kvm head is OK. [0] 865aa3fec2b3d83c9b6edd452050a30ef6eaf3b8 [1] 8c7d4cb7163d1c97df4439e2e0edb5918abf106b [2] d6d233543d543fcf34df6190bbce5daf38d870f5 kvm-autotest and you won't have to fix it again... -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 05:20:38PM +0200, Avi Kivity wrote: On 09/19/2010 01:59 PM, Gleb Natapov wrote: I fixed it several times in the past[0][1][3], but it keeps re-appearing :) I hope current qemu-kvm head is OK. [0] 865aa3fec2b3d83c9b6edd452050a30ef6eaf3b8 [1] 8c7d4cb7163d1c97df4439e2e0edb5918abf106b [2] d6d233543d543fcf34df6190bbce5daf38d870f5 kvm-autotest and you won't have to fix it again... Heh. Can't argue with this. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
I need to know if a cpu is currently inserted or ejected. The only way to do that currently is to track it in your management app. The Management App does know which one should be inserted or ejected. I see now way of enforcing it though. This is what I had in mind: (simplified) 1. Management App increase cpus 2. kvm (as instructed by app): insert cpu x 3. guest os: online cpu x 4. do some stuff in the guest... 5. guest os: offline cpu x 6. Management App decrease cpus 7. kvm (as instructed by app): eject cpu x However after step 7 the guest can turn the cpu online again by issuing echo 1 /sys/devices/.../cpuX/online If the guest does so, the Management App has no way of knowing and thus cannot provide accurate logs - that is why it is so important. Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 05:37:18PM +0200, Conrad Wood wrote: I need to know if a cpu is currently inserted or ejected. The only way to do that currently is to track it in your management app. The Management App does know which one should be inserted or ejected. I see now way of enforcing it though. This is what I had in mind: (simplified) 1. Management App increase cpus 2. kvm (as instructed by app): insert cpu x 3. guest os: online cpu x 4. do some stuff in the guest... 5. guest os: offline cpu x 6. Management App decrease cpus 7. kvm (as instructed by app): eject cpu x However after step 7 the guest can turn the cpu online again by issuing echo 1 /sys/devices/.../cpuX/online There will be no /sys/devices/.../cpuX/online in guest after step 7. If the guest does so, the Management App has no way of knowing and thus cannot provide accurate logs - that is why it is so important. Conrad -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
However after step 7 the guest can turn the cpu online again by issuing echo 1 /sys/devices/.../cpuX/online There will be no /sys/devices/.../cpuX/online in guest after step 7. Well then at least in my version there's a bug, because it still is there and never goes away. (kvm 0.12.5) And changing it to online works as well. Which version are you using? Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote: However after step 7 the guest can turn the cpu online again by issuing echo 1 /sys/devices/.../cpuX/online There will be no /sys/devices/.../cpuX/online in guest after step 7. Well then at least in my version there's a bug, because it still is there and never goes away. (kvm 0.12.5) And changing it to online works as well. Can you provide exact steps you are using? After doing cpu_set x offline cpu x should disappear from a guest. Otherwise cpu eject didn't work. Which version are you using? Nothing :) I am saying how it should work. Last time I played with cpu hot-plug was with qemu-kvm 0.11.x. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 05:53:47PM +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote: However after step 7 the guest can turn the cpu online again by issuing echo 1 /sys/devices/.../cpuX/online There will be no /sys/devices/.../cpuX/online in guest after step 7. Well then at least in my version there's a bug, because it still is there and never goes away. (kvm 0.12.5) And changing it to online works as well. Can you provide exact steps you are using? After doing cpu_set x offline cpu x should disappear from a guest. Otherwise cpu eject didn't work. I'm confused. The cpu_set x offline doesn't appear to do anything for me. It does not disable the cpu, nor does it inform the guest to disable the cpu. The only way I'm able to remove a cpu is to run in the guest: echo 1 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:xx/eject which (as far as I know) is purely a voluntary guest disable of the cpu. It doesn't (as far as I know) even tell kvm that it is no longer using the cpu. (The acpi cpu eject method in seabios just issues a sleep(200) call.) -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 12:04:51PM -0400, Kevin O'Connor wrote: On Sun, Sep 19, 2010 at 05:53:47PM +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote: However after step 7 the guest can turn the cpu online again by issuing echo 1 /sys/devices/.../cpuX/online There will be no /sys/devices/.../cpuX/online in guest after step 7. Well then at least in my version there's a bug, because it still is there and never goes away. (kvm 0.12.5) And changing it to online works as well. Can you provide exact steps you are using? After doing cpu_set x offline cpu x should disappear from a guest. Otherwise cpu eject didn't work. I'm confused. The cpu_set x offline doesn't appear to do anything for me. It does not disable the cpu, nor does it inform the guest to disable the cpu. The only way I'm able to remove a cpu is to run in the guest: echo 1 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:xx/eject which (as far as I know) is purely a voluntary guest disable of the cpu. It doesn't (as far as I know) even tell kvm that it is no longer using the cpu. (The acpi cpu eject method in seabios just issues a sleep(200) call.) Then cpu eject method in seabios has a bug. When cpu_set x offline is called qemu sets status bit in gpe and injects ACPI interrupt. ACPI should do Notify() on cpu object when it happens. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, 2010-09-19 at 12:04 -0400, Kevin O'Connor wrote:
On Sun, Sep 19, 2010 at 05:53:47PM +0200, Gleb Natapov wrote:
On Sun, Sep 19, 2010 at 05:44:00PM +0200, Conrad Wood wrote:
However after step 7 the guest can turn the cpu online again by
issuing
echo 1 /sys/devices/.../cpuX/online
There will be no /sys/devices/.../cpuX/online in guest after step 7.
Well then at least in my version there's a bug, because it still is
there and never goes away. (kvm 0.12.5)
And changing it to online works as well.
Can you provide exact steps you are using? After doing cpu_set x offline
cpu x should disappear from a guest. Otherwise cpu eject didn't work.
I'm confused. The cpu_set x offline doesn't appear to do anything
for me. It does not disable the cpu, nor does it inform the guest to
disable the cpu.
I second that - same here.
a script with my exact steps is below. Result is reproducible.
When run on my system it will output:
Known CPUs are defined as cpus with an entry
in /sys/devices/system/cpu on the guest
Inserted CPUs are defined as cpus listed by info cpus in qemu monitor
online CPUs are defined as cpus listed in /proc/cpuinfo on the guest
Inserted CPUs: 4, CPUs known to the guest: 4, ONLINE in guest: 4
Inserting CPU #4
Inserted CPUs: 5, CPUs known to the guest: 5, ONLINE in guest: 4
Ejecting CPU #4
Inserted CPUs: 5, CPUs known to the guest: 5, ONLINE in guest: 4
Setting all available cpus to online...
bash: line 0: echo: write error: Invalid argument
bash: line 0: echo: write error: Invalid argument
bash: line 0: echo: write error: Invalid argument
Inserted CPUs: 5, CPUs known to the guest: 5, ONLINE in guest: 5
^
after cpu_set 4 offline this should not come online again!!
---
#!/bin/bash
VM=192.168.2.35
MONITORHOST=localhost
MONITORPORT=9401
# count how many cpus are in /proc/cpuinfo on the guest
countOnline() {
ONLINECPUS=`ssh -lroot ${VM} grep processor /proc/cpuinfo | wc -l`
}
# count how many cpus are in /sys/devices/...
countCPUsKnown() {
KNOWNCPUS=`ssh -lroot ${VM} find /sys/devices/system/cpu/ -name
'cpu?'| wc -l`
}
# count how many cpus does kvm list
countInserted() {
INSERTEDCPUS=`echo info cpus | nc ${MONITORHOST} ${MONITORPORT} |
grep -av '(qemu)'|grep -va 'for more inform'|wc -l`
}
printInfo() {
countOnline
countCPUsKnown
countInserted
echo Inserted CPUs: ${INSERTEDCPUS}, CPUs known to the guest:
${KNOWNCPUS}, ONLINE in guest: ${ONLINECPUS}
}
echo \Known CPUs\ are defined as cpus with an entry
in /sys/devices/system/cpu on the guest
echo \Inserted CPUs\ are defined as cpus listed by info cpus in qemu
monitor
echo \online CPUs\ are defined as cpus listed in /proc/cpuinfo on the
guest
echo
printInfo
echo Inserting CPU #4
echo cpu_set 4 online | nc ${MONITORHOST} ${MONITORPORT} /dev/null
printInfo
echo Ejecting CPU #4
echo cpu_set 4 offline | nc ${MONITORHOST} ${MONITORPORT} /dev/null
printInfo
echo Setting all available cpus to online...
ssh -lroot ${VM} find /sys/devices/system/cpu/ -type f -path
'*/cpu?/online' -exec bash -c \echo 1 {}\ \;
printInfo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 06:24:33PM +0200, Conrad Wood wrote:
a script with my exact steps is below. Result is reproducible.
[...]
echo Ejecting CPU #4
echo cpu_set 4 offline | nc ${MONITORHOST} ${MONITORPORT} /dev/null
printInfo
echo Setting all available cpus to online...
ssh -lroot ${VM} find /sys/devices/system/cpu/ -type f -path
'*/cpu?/online' -exec bash -c \echo 1 {}\ \;
It's not clear if you can trust your guests or not. If you can trust
the guest OS, it should be safe to run:
echo 1 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:xx/eject
in the guest. A normal linux guest wont reactivate the cpu after
that.
-Kevin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sun, Sep 19, 2010 at 06:12:14PM +0200, Gleb Natapov wrote: On Sun, Sep 19, 2010 at 12:04:51PM -0400, Kevin O'Connor wrote: I'm confused. The cpu_set x offline doesn't appear to do anything for me. It does not disable the cpu, nor does it inform the guest to disable the cpu. [...] Then cpu eject method in seabios has a bug. When cpu_set x offline is called qemu sets status bit in gpe and injects ACPI interrupt. ACPI should do Notify() on cpu object when it happens. I was wrong. The cpu_set x offline does send an event to the guest OS. SeaBIOS even forwards the event along - as far as I can tell a Notify(CPxx, 3) event is generated by SeaBIOS. My Windows 7 ultimate beta seems to receive the event okay (it pops up a dialog box which says you can't unplug cpus). Unfortunately, my test linux guest OS (FC13) doesn't seem to do anything with the unplug Notify event. I've tried with the original FC13 and with a fully updated version - no luck. So, I'm guessing this has something to do with the guest OS. -Kevin -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sat, 2010-09-18 at 10:32 -0400, Kevin O'Connor wrote: On Fri, Sep 17, 2010 at 11:39:36PM +0200, Conrad Wood wrote: Hi everyone, I'm currently looking into hotplugging CPUs. This exclusively with linux-guests and linux-host. I have found some (conflicting) information about this on the net. As far as I read: * seabios doesn't support SMP (but why does the linux-guest show multiple cpus?) * there is no uniform way of informing the linux kernel that a cpu has added (Found references to a unisys way of doing it though, which seems to be still implemented) * the kernel needs the acpi tables to determine how many cpus it has, thus the support in the bios would involve an aml-compiler to hot-compile new acpi tables. SeaBIOS version 0.6.1 has ACPI support for cpu-hotplug. It's been tested on Linux and Windows. Search the mail archive for cpu hotplug for the details. -Kevin Now... that would save some time ;) Thank you! Conrad -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cpu hotplug
On Sat, 2010-09-18 at 10:32 -0400, Kevin O'Connor wrote:
On Fri, Sep 17, 2010 at 11:39:36PM +0200, Conrad Wood wrote:
Hi everyone,
I'm currently looking into hotplugging CPUs.
This exclusively with linux-guests and linux-host.
I have found some (conflicting) information about this on the net.
As far as I read:
* seabios doesn't support SMP (but why does the linux-guest show
multiple cpus?)
* there is no uniform way of informing the linux kernel that a cpu has
added (Found references to a unisys way of doing it though, which seems
to be still implemented)
* the kernel needs the acpi tables to determine how many cpus it has,
thus the support in the bios would involve an aml-compiler to
hot-compile new acpi tables.
SeaBIOS version 0.6.1 has ACPI support for cpu-hotplug. It's been
tested on Linux and Windows. Search the mail archive for cpu
hotplug for the details.
-Kevin
hm... after upgrading to seabios 0.6.1 and qemu-kvm 0.13.50 (git today)
I get:
qemu-kvm/hw/qdev.c:94: qdev_create_from_info: Assertion
`bus-allow_hotplug' failed.
when I issue cpu_set 4 online on the cmd line. ;(
starting with commandline:
/usr/local/kvm/bin/qemu-system-x86_64 -M pc \
-bios /usr/local/kvm/seabios/latest \
-cpu phenom -enable-kvm -m 1024 -smp 4,cores=2,maxcpus=30,threads=1
-name testapp -uuid 5ee3d553-f6a4-0f33-6823-ee16a16a7fb4 -nodefaults \
-numa 2 \
-monitor telnet:localhost:9401,server,nowait -rtc base=utc -boot
${BOOTSTRAP} -device
rtl8139,vlan=0,id=net0,mac=52:54:01:65:e6:70,bus=pci.0,addr=0x4 \
-net tap,ifname=cnw0 -chardev pty,id=serial0 -device
isa-serial,chardev=serial0 -k en-gb -vga cirrus \
-drive
file=/srv/kvm/test-app.qcow2,if=virtio,cache=writeback,bus=0,id=a0,index=0,media=disk,format=qcow2,serial=1,boot=on,snapshot=${SNAPSHOT}
\
-nodefaults \
-${WD} \
--enable-nesting \
any ideas ?
Conrad
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
2010/1/10 Gleb Natapov g...@redhat.com: On Sun, Jan 10, 2010 at 05:33:02PM +0900, Ryota Ozaki wrote: [...] I see. Anyway I think we need some workaround to avoid segfault. Disabling cpu_set command for qemu-kvm-0.12 is good enough workaround. Agree. I'll send a patch. but ACPI code that handles CPU host-plug was not ported to SeaBIOS when it replaces BOCH BIOS. Yeah, I confirmed it during memory hotplug work... So I'd like to know when cpu hotplug comes back? I didn't see it in qemu-0.13 feature requests. May I ask what do you need it for? Oh sorry, actually I have not so strong desire on cpu hotplug but I have on memory hotplug and just want to learn stuffs to implement it from cpu's one. Honestly said I'm not sure someone want it. The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? And also I want to ask that the problem can be applied to memory hotplug case? Thanks, ozaki-r -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 06:24:32PM +0900, Ryota Ozaki wrote: 2010/1/10 Gleb Natapov g...@redhat.com: On Sun, Jan 10, 2010 at 05:33:02PM +0900, Ryota Ozaki wrote: [...] I see. Anyway I think we need some workaround to avoid segfault. Disabling cpu_set command for qemu-kvm-0.12 is good enough workaround. Agree. I'll send a patch. Thanks. but ACPI code that handles CPU host-plug was not ported to SeaBIOS when it replaces BOCH BIOS. Yeah, I confirmed it during memory hotplug work... So I'd like to know when cpu hotplug comes back? I didn't see it in qemu-0.13 feature requests. May I ask what do you need it for? Oh sorry, actually I have not so strong desire on cpu hotplug but I have on memory hotplug and just want to learn stuffs to implement it from cpu's one. Honestly said I'm not sure someone want it. Hmm, everybody want it, but nobody can't say why. Looks like it just sounds cool :) The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? I have no idea how it works in Windows. It seems that some kind of driver is required for hot-plugging cpu there. Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? What do you mean by different implementation? Different one for Windows and Linux and have a switch to choose one? Possible, but not desirable. Different from what we had in BOCHS BIOS? Also possible, but will require changes to Linux kernel and older Kernel will not work. And also I want to ask that the problem can be applied to memory hotplug case? AFAIK memory hotplug is part of ACPI spec and if implemented correctly should not cause any problems. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 6:32 PM, Gleb Natapov g...@redhat.com wrote: On Mon, Jan 11, 2010 at 06:24:32PM +0900, Ryota Ozaki wrote: 2010/1/10 Gleb Natapov g...@redhat.com: [...] May I ask what do you need it for? Oh sorry, actually I have not so strong desire on cpu hotplug but I have on memory hotplug and just want to learn stuffs to implement it from cpu's one. Honestly said I'm not sure someone want it. Hmm, everybody want it, but nobody can't say why. Looks like it just sounds cool :) I cannot disclaim that :) If we have textbookish answers, they will be somewhat We have a physical machine could have multiple VMs and the number of VMs dynamically varies, so we need to change the number of VCPUs of the VMs on the fly to gain maximum throughput or A migrated VM may have an opportunity to get more VCPUs so far because the destination physical machine has more number of CPUs than source one., however, I have not ever faced such situations. The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? I have no idea how it works in Windows. It seems that some kind of driver is required for hot-plugging cpu there. I see. Thanks. I'll check it and also VMware case that likely supports the function. Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? What do you mean by different implementation? Different one for Windows and Linux and have a switch to choose one? Possible, but not desirable. Different from what we had in BOCHS BIOS? Also possible, but will require changes to Linux kernel and older Kernel will not work. I mean the former one. I think it'd be a way to have cpu hotplug supports for both Linxu and Windows (and others), but yes, it's the case only if the supports are really really desired. So I want to hear the comments by someones using CPU hotplug functions in real use if exist. And also I want to ask that the problem can be applied to memory hotplug case? AFAIK memory hotplug is part of ACPI spec and if implemented correctly should not cause any problems. That makes me happy ;-) Thank you for telling me! ozaki-r -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On 01/11/2010 11:24 AM, Ryota Ozaki wrote: The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 12:23:05PM +0200, Avi Kivity wrote: On 01/11/2010 11:24 AM, Ryota Ozaki wrote: The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. That cool, but SVVP complains. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On 01/11/2010 12:24 PM, Gleb Natapov wrote: IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 7:23 PM, Avi Kivity a...@redhat.com wrote: On 01/11/2010 11:24 AM, Ryota Ozaki wrote: The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. Could I ask you what's the difference between the two implementations? Don't we have a possibility to have different implementations in qemu-kvm (and SeaBIOS)? IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. Oh, pleasure to hear it ;-) ozaki-r -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 12:25:52PM +0200, Avi Kivity wrote: On 01/11/2010 12:24 PM, Gleb Natapov wrote: IMO we should stick with the unisys-derived implementation, port it to SeaBIOS, and write a Windows driver for it. It has the advantage of having support in Linux, and of being somewhat tested. That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. https://bugzilla.redhat.com/show_bug.cgi?id=49584://bugzilla.redhat.com/show_bug.cgi?id=495844 Hope it accessible to everyone but if not SVVP complains: Run Signed Driver check of SVVP testing, the (Qemu virtual CPU verison 0.9.1) has error. The only why to fix it that I can see is to not present disabled MADT entries for Windows and that will require us to provide some kind of flag to QEMU. The cleanest way is to create disabled MADT entries only if max-cpus != startup cpus and run Windows only with max-cpus == startup cpus. The problem is 1) you have to know what is your guest at startup time 2) will require creation of SSDT for Processors() on the fly (or precompile them for every value of max-cpus and load dynamically). Actually there is a third solution that I just thought about but I need to test it first :). Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On 01/11/2010 12:42 PM, Gleb Natapov wrote: That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. https://bugzilla.redhat.com/show_bug.cgi?id=49584://bugzilla.redhat.com/show_bug.cgi?id=495844 Hope it accessible to everyone but if not SVVP complains: Run Signed Driver check of SVVP testing, the (Qemu virtual CPU verison 0.9.1) has error. The only why to fix it that I can see is to not present disabled MADT entries for Windows and that will require us to provide some kind of flag to QEMU. The cleanest way is to create disabled MADT entries only if max-cpus != startup cpus and run Windows only with max-cpus == startup cpus. The problem is 1) you have to know what is your guest at startup time 2) will require creation of SSDT for Processors() on the fly (or precompile them for every value of max-cpus and load dynamically). Actually there is a third solution that I just thought about but I need to test it first :). Perhaps loading a processor driver will fix this issue (which driver can also perform the hotplug). Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 12:50:05PM +0200, Avi Kivity wrote: On 01/11/2010 12:42 PM, Gleb Natapov wrote: That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. https://bugzilla.redhat.com/show_bug.cgi?id=49584://bugzilla.redhat.com/show_bug.cgi?id=495844 Hope it accessible to everyone but if not SVVP complains: Run Signed Driver check of SVVP testing, the (Qemu virtual CPU verison 0.9.1) has error. The only why to fix it that I can see is to not present disabled MADT entries for Windows and that will require us to provide some kind of flag to QEMU. The cleanest way is to create disabled MADT entries only if max-cpus != startup cpus and run Windows only with max-cpus == startup cpus. The problem is 1) you have to know what is your guest at startup time 2) will require creation of SSDT for Processors() on the fly (or precompile them for every value of max-cpus and load dynamically). Actually there is a third solution that I just thought about but I need to test it first :). Perhaps loading a processor driver will fix this issue (which driver can also perform the hotplug). Perhaps, perhaps not, who are looking into it? I know the problem I don't know solution. Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. Eventually yes, but can you say now that it will not require DSDT changes or command line parameter? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On 01/11/2010 12:53 PM, Gleb Natapov wrote: Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. Eventually yes, but can you say now that it will not require DSDT changes or command line parameter? No, but I'm not really worried about that. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 12:58:24PM +0200, Avi Kivity wrote: On 01/11/2010 12:53 PM, Gleb Natapov wrote: Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. Eventually yes, but can you say now that it will not require DSDT changes or command line parameter? No, but I'm not really worried about that. So you want to introduce something that we know upset Windows without looking into alternatives. And as far as I remember upstream position on the UNISYS way was negative, did this change? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On 01/11/2010 01:03 PM, Gleb Natapov wrote: No, but I'm not really worried about that. So you want to introduce something that we know upset Windows without looking into alternatives. I don't want to drop support for existing guests unless I have to. And as far as I remember upstream position on the UNISYS way was negative, did this change? I don't see anything fundamentally wrong with the unisys implementation. True, it's not written to any spec, but neither is anything we can come up with (unless we find a spec for cpu hotplug). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Mon, Jan 11, 2010 at 01:06:24PM +0200, Avi Kivity wrote: On 01/11/2010 01:03 PM, Gleb Natapov wrote: No, but I'm not really worried about that. So you want to introduce something that we know upset Windows without looking into alternatives. I don't want to drop support for existing guests unless I have to. Neither do I and I would be happy with what we had if SVVP wouldn't complain. So we need some kind of fix, or exception for the test. And as far as I remember upstream position on the UNISYS way was negative, did this change? I don't see anything fundamentally wrong with the unisys implementation. True, it's not written to any spec, but neither is anything we can come up with (unless we find a spec for cpu hotplug). -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On 01/11/2010 04:50 AM, Avi Kivity wrote: On 01/11/2010 12:42 PM, Gleb Natapov wrote: That cool, but SVVP complains. What's the complaint? Maybe we can fix it instead of rewriting things. https://bugzilla.redhat.com/show_bug.cgi?id=49584://bugzilla.redhat.com/show_bug.cgi?id=495844 Hope it accessible to everyone but if not SVVP complains: Run Signed Driver check of SVVP testing, the (Qemu virtual CPU verison 0.9.1) has error. The only why to fix it that I can see is to not present disabled MADT entries for Windows and that will require us to provide some kind of flag to QEMU. The cleanest way is to create disabled MADT entries only if max-cpus != startup cpus and run Windows only with max-cpus == startup cpus. The problem is 1) you have to know what is your guest at startup time 2) will require creation of SSDT for Processors() on the fly (or precompile them for every value of max-cpus and load dynamically). Actually there is a third solution that I just thought about but I need to test it first :). Perhaps loading a processor driver will fix this issue (which driver can also perform the hotplug). Anyway all those solution do not guaranty that we will be able to do cpu hotplug on Windows since we don't yet know what Windows expects. I'm sure we'll be able to eventually. win2k8 supports CPU hotplug with VMware. I'd suggest someone fire up VMware and dump the ACPI tables to try and see how they're doing it. Otherwise, if someone has a physical machine that is known to do CPU hotplug with win2k8, an acpi dump would be useful there. I think it's easier to make sure Linux works with what Windows currently supports than vice versa. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On 01/11/2010 03:57 PM, Anthony Liguori wrote: win2k8 supports CPU hotplug with VMware. I'd suggest someone fire up VMware and dump the ACPI tables to try and see how they're doing it. Otherwise, if someone has a physical machine that is known to do CPU hotplug with win2k8, an acpi dump would be useful there. I think it's easier to make sure Linux works with what Windows currently supports than vice versa. Gleb found some presentation that describes Windows cpu hotplug as something very similar to what we do today, so hopefully the whole issue is just a bug or missing feature in the implementation. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Sun, Jan 10, 2010 at 05:33:02PM +0900, Ryota Ozaki wrote: On Sun, Jan 10, 2010 at 3:39 PM, Gleb Natapov g...@redhat.com wrote: On Sat, Jan 09, 2010 at 04:30:11PM -0300, Daniel Bareiro wrote: On Friday, 08 January 2010 19:35:04 +0900, Ryota Ozaki wrote: Hi all, Hi, Ryota. I've tried CPU hotplug with latest qemu-kvm.git code, and got segmentation fault. I'm also having this problem but with Linux 2.6.32.2 + qemu-kvm-0.12.1.1 in the host: Jan 9 16:11:11 ubuntu kernel: [758479.480219] qemu-system-x86[29330]: segfault at 90 ip 7f5816bf3990 sp 7fff9258fc88 error 4 in libpthread-2.7.so[7f5816be8000+16000] I've guest with one cpu in which I try to add one more. For this I execute the following in qemu monitor and here it is where I got segmentation fault: (qemu) cpu_set 1 online Connection closed by foreign host. I'm not sure if the procedure that I'm following is the correct one. I tried as much without using additional parameters when boots guest like using -smp 1,maxcpus=2, but I reach the same result. The Kernel of guest has checked the Support for hot-pluggable CPUs option, in case it is necessary. CPU host-plug is not supported on qemu-kvm-0.12. It shouldn't segfault obviously, I see. Anyway I think we need some workaround to avoid segfault. Disabling cpu_set command for qemu-kvm-0.12 is good enough workaround. but ACPI code that handles CPU host-plug was not ported to SeaBIOS when it replaces BOCH BIOS. Yeah, I confirmed it during memory hotplug work... So I'd like to know when cpu hotplug comes back? I didn't see it in qemu-0.13 feature requests. May I ask what do you need it for? The problem is that there is no standard way to hotplug CPUs in a PC. Linux implements the way UNISYS happen to do it, but no other system do it like that. Windows implements it differently and in the way that conflicts with Linux, so you can't have working Linux implementation and pass Microsoft SVVP test at the same time for instance. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CPU hotplug add seems broken
On Friday, 08 January 2010 19:35:04 +0900, Ryota Ozaki wrote: Hi all, Hi, Ryota. I've tried CPU hotplug with latest qemu-kvm.git code, and got segmentation fault. I'm also having this problem but with Linux 2.6.32.2 + qemu-kvm-0.12.1.1 in the host: Jan 9 16:11:11 ubuntu kernel: [758479.480219] qemu-system-x86[29330]: segfault at 90 ip 7f5816bf3990 sp 7fff9258fc88 error 4 in libpthread-2.7.so[7f5816be8000+16000] I've guest with one cpu in which I try to add one more. For this I execute the following in qemu monitor and here it is where I got segmentation fault: (qemu) cpu_set 1 online Connection closed by foreign host. I'm not sure if the procedure that I'm following is the correct one. I tried as much without using additional parameters when boots guest like using -smp 1,maxcpus=2, but I reach the same result. The Kernel of guest has checked the Support for hot-pluggable CPUs option, in case it is necessary. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature
Re: CPU hotplug add seems broken
On Sat, Jan 09, 2010 at 04:30:11PM -0300, Daniel Bareiro wrote: On Friday, 08 January 2010 19:35:04 +0900, Ryota Ozaki wrote: Hi all, Hi, Ryota. I've tried CPU hotplug with latest qemu-kvm.git code, and got segmentation fault. I'm also having this problem but with Linux 2.6.32.2 + qemu-kvm-0.12.1.1 in the host: Jan 9 16:11:11 ubuntu kernel: [758479.480219] qemu-system-x86[29330]: segfault at 90 ip 7f5816bf3990 sp 7fff9258fc88 error 4 in libpthread-2.7.so[7f5816be8000+16000] I've guest with one cpu in which I try to add one more. For this I execute the following in qemu monitor and here it is where I got segmentation fault: (qemu) cpu_set 1 online Connection closed by foreign host. I'm not sure if the procedure that I'm following is the correct one. I tried as much without using additional parameters when boots guest like using -smp 1,maxcpus=2, but I reach the same result. The Kernel of guest has checked the Support for hot-pluggable CPUs option, in case it is necessary. CPU host-plug is not supported on qemu-kvm-0.12. It shouldn't segfault obviously, but ACPI code that handles CPU host-plug was not ported to SeaBIOS when it replaces BOCH BIOS. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
