CPU hotplug add seems broken

CPU hotplug add seems broken

[Ryota Ozaki]

Hi all,

I've tried CPU hotplug with latest qemu-kvm.git code,
and got segmentation fault.

Call trace of the qemu-system-x86_64 is like this:

(gdb) where
#0  0x0000003cec80c280 in pthread_kill () from /lib64/libpthread.so.0
#1  0x000000000042fd72 in on_vcpu (env=0x2b24080,
    func=0x42ffd7 <kvm_do_load_mpstate>, data=0x2b24080)
    at /home/ozaki-r/git/qemu-kvm/qemu-kvm.c:1529
#2  0x000000000043002e in kvm_load_mpstate (env=0x2b24080)
    at /home/ozaki-r/git/qemu-kvm/qemu-kvm.c:1622
#3  0x000000000059197a in apic_init_reset (env=0x2b24080)
    at /home/ozaki-r/git/qemu-kvm/hw/apic.c:515
#4  0x0000000000592f07 in apic_reset (opaque=0x2a32d00)
    at /home/ozaki-r/git/qemu-kvm/hw/apic.c:1080
#5  0x0000000000593047 in apic_init (env=0x2b24080)
    at /home/ozaki-r/git/qemu-kvm/hw/apic.c:1137
#6  0x000000000056e7a9 in pc_new_cpu (cpu_model=0x6063b3 "qemu64")
    at /home/ozaki-r/git/qemu-kvm/hw/pc.c:984
#7  0x0000000000595d6b in qemu_system_cpu_hot_add (cpu=2, state=1)
    at /home/ozaki-r/git/qemu-kvm/hw/acpi.c:781
#8  0x0000000000414a83 in do_cpu_set_nr (mon=0x2af8b80, qdict=0x2af4920)
    at /home/ozaki-r/git/qemu-kvm/monitor.c:832
#9  0x0000000000419105 in handle_user_command (mon=0x2af8b80,
    cmdline=0x2d6e970 "cpu_set 2 online")
    at /home/ozaki-r/git/qemu-kvm/monitor.c:3671
#10 0x000000000041a400 in monitor_command_cb (mon=0x2af8b80,
    cmdline=0x2d6e970 "cpu_set 2 online", opaque=0x0)
    at /home/ozaki-r/git/qemu-kvm/monitor.c:4179
#11 0x0000000000474577 in readline_handle_byte (rs=0x2d6e970, ch=10)
    at readline.c:369
#12 0x000000000041a367 in monitor_read (opaque=0x2af8b80,
    buf=0x7ffff1c9a3c0 "\n\244\311\361\377\177", size=1)
    at /home/ozaki-r/git/qemu-kvm/monitor.c:4165
#13 0x000000000049856f in qemu_chr_read (s=0x29a6280,
    buf=0x7ffff1c9a3c0 "\n\244\311\361\377\177", len=1) at qemu-char.c:154
#14 0x0000000000476f6a in kbd_send_chars (opaque=0x2a69ec0) at console.c:1130
#15 0x0000000000477184 in kbd_put_keysym (keysym=10) at console.c:1183
#16 0x00000000004b704a in curses_refresh (ds=0x2a4b440) at curses.c:270
#17 0x0000000000408de1 in dpy_refresh (s=0x2a4b440)
    at /home/ozaki-r/git/qemu-kvm/console.h:219
#18 0x000000000040dfd9 in gui_update (opaque=0x2a4b440)
    at /home/ozaki-r/git/qemu-kvm/vl.c:3230
#19 0x000000000040a1ea in qemu_run_timers (ptimer_head=0x89bdc0,
    current_time=5844186) at /home/ozaki-r/git/qemu-kvm/vl.c:1127
#20 0x000000000040ebd6 in main_loop_wait (timeout=1000)
    at /home/ozaki-r/git/qemu-kvm/vl.c:4036
#21 0x0000000000430f66 in kvm_main_loop ()
    at /home/ozaki-r/git/qemu-kvm/qemu-kvm.c:2121
#22 0x000000000040f0ba in main_loop () at /home/ozaki-r/git/qemu-kvm/vl.c:4209
#23 0x0000000000412d86 in main (argc=14, argv=0x7ffff1c9ab68,
    envp=0x7ffff1c9abe0) at /home/ozaki-r/git/qemu-kvm/vl.c:6237
(gdb) list
1524            env->kvm_cpu_state.queued_work_last->next = &wi;
1525        env->kvm_cpu_state.queued_work_last = &wi;
1526        wi.next = NULL;
1527        wi.done = false;
1528
1529        pthread_kill(env->kvm_cpu_state.thread, SIG_IPI);
1530        while (!wi.done)
1531            qemu_cond_wait(&qemu_work_cond);
1532    }
1533
(gdb) print env->kvm_cpu_state.thread
$1 = 0


This looks like the thread is not created when sending SIG_IPI.

My short investigation says current code calls pthread_kill()
before pthread_create():

qemu_system_cpu_hot_add
=> pc_new_cpu
     => cpu_init
     => apic_init
          => apic_reset
               => apic_init_reset
                    => kvm_load_mpstate
                         => on_vcpu
                              => pthread_kill
     => qemu_init_vcpu
          => kvm_init_vcpu
               => pthread_create


Any ideas for fix?


Note that commit id is
  855ea2a3cd4ebb15bfe328023f6df29bacbffc85
and qemu command line is
  qemu-system-x86_64 -hda vm.img -kernel /boot/vmlinuz-2.6.33-rc3 \
    -initrd /boot/initramfs-2.6.33-rc3.img -append 'root=/dev/sda3 ro quiet' \
    -curses -smp 2,maxcpus=4
and command in qemu console is
  cpu_set 2 online


Thanks in advance,
  ozaki-r

Re: CPU hotplug add seems broken

[Daniel Bareiro]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

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 00007f5816bf3990 sp 00007fff9258fc88 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: CPU hotplug add seems broken

[Gleb Natapov]

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 00007f5816bf3990 sp 00007fff9258fc88 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.

Re: CPU hotplug add seems broken

[Ryota Ozaki]

On Sun, Jan 10, 2010 at 3:39 PM, Gleb Natapov <gleb@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 00007f5816bf3990 sp 00007fff9258fc88 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.

> 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.

  ozaki-r

>
> --
>                        Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: CPU hotplug add seems broken

[Gleb Natapov]

On Sun, Jan 10, 2010 at 05:33:02PM +0900, Ryota Ozaki wrote:
> On Sun, Jan 10, 2010 at 3:39 PM, Gleb Natapov <gleb@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 00007f5816bf3990 sp 00007fff9258fc88 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.

Re: CPU hotplug add seems broken

[Ryota Ozaki]

2010/1/10 Gleb Natapov <gleb@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.
>

Re: CPU hotplug add seems broken

[Gleb Natapov]

On Mon, Jan 11, 2010 at 06:24:32PM +0900, Ryota Ozaki wrote:
> 2010/1/10 Gleb Natapov <gleb@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.

Re: CPU hotplug add seems broken

[Ryota Ozaki]

On Mon, Jan 11, 2010 at 6:32 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Mon, Jan 11, 2010 at 06:24:32PM +0900, Ryota Ozaki wrote:
>> 2010/1/10 Gleb Natapov <gleb@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.
>

Re: CPU hotplug add seems broken

[Avi Kivity]

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

Re: CPU hotplug add seems broken

[Gleb Natapov]

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.

Re: CPU hotplug add seems broken

[Avi Kivity]

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

Re: CPU hotplug add seems broken

[Ryota Ozaki]

On Mon, Jan 11, 2010 at 7:23 PM, Avi Kivity <avi@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
>
>

Re: CPU hotplug add seems broken

[Gleb Natapov]

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.

Re: CPU hotplug add seems broken

[Avi Kivity]

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

Re: CPU hotplug add seems broken

[Gleb Natapov]

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.

Re: CPU hotplug add seems broken

[Avi Kivity]

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

Re: CPU hotplug add seems broken

[Gleb Natapov]

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.

Re: CPU hotplug add seems broken

[Avi Kivity]

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

Re: CPU hotplug add seems broken

[Gleb Natapov]

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.

Re: CPU hotplug add seems broken

[Anthony Liguori]

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

Re: CPU hotplug add seems broken

[Avi Kivity]

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