Reconciling qemu-kvm and qemu's PIT

Reconciling qemu-kvm and qemu's PIT

[Avi Kivity]

VMStateDescription vmstate_pit = {
    .name = "i8254",
    .version_id = 3,
    .minimum_version_id = 2,
    .minimum_version_id_old = 1,
    .load_state_old = pit_load_old,
    .fields      = (VMStateField []) {
<<<<<<< HEAD
        VMSTATE_UINT32(flags, PITState),
||||||| merged common ancestors
=======
        VMSTATE_UINT32_V(channels[0].irq_disabled, PITState, 3),
>>>>>>> ce967e2f33861b0e17753f97fa4527b5943c94b6
        VMSTATE_STRUCT_ARRAY(channels, PITState, 3, 2,
vmstate_pit_channel, PITChannelState),
        VMSTATE_TIMER(channels[0].irq_timer, PITState),
        VMSTATE_END_OF_LIST()
    }
};

I'm guessing that flags and irq_disabled are equivalent, but do they
have the same sense (that is, do the "1" values have the same meaning)? 
If not, we have a migration problem.

Is it save to just adopt the new version and drop the old one?

-- 
error compiling committee.c: too many arguments to function

Re: Reconciling qemu-kvm and qemu's PIT

[Jan Kiszka]

On 2012-02-28 15:32, Avi Kivity wrote:
> 
> VMStateDescription vmstate_pit = {
>     .name = "i8254",
>     .version_id = 3,
>     .minimum_version_id = 2,
>     .minimum_version_id_old = 1,
>     .load_state_old = pit_load_old,
>     .fields      = (VMStateField []) {
> <<<<<<< HEAD
>         VMSTATE_UINT32(flags, PITState),
> ||||||| merged common ancestors
> =======
>         VMSTATE_UINT32_V(channels[0].irq_disabled, PITState, 3),
>>>>>>>> ce967e2f33861b0e17753f97fa4527b5943c94b6
>         VMSTATE_STRUCT_ARRAY(channels, PITState, 3, 2,
> vmstate_pit_channel, PITChannelState),
>         VMSTATE_TIMER(channels[0].irq_timer, PITState),
>         VMSTATE_END_OF_LIST()
>     }
> };
> 
> I'm guessing that flags and irq_disabled are equivalent, but do they
> have the same sense (that is, do the "1" values have the same meaning)? 

Yes. qemu-kvm sets flags to 0 or PIT_FLAGS_HPET_LEGACY, which is 1. And
the latter means "irq_disabled".

> If not, we have a migration problem.
> 
> Is it save to just adopt the new version and drop the old one?

The new upstream code was designed to match qemu-kvm's migration format,
so you can switch. Of course, the result needs a careful check.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Reconciling qemu-kvm and qemu's PIT

[Avi Kivity]

On 02/28/2012 04:40 PM, Jan Kiszka wrote:
> On 2012-02-28 15:32, Avi Kivity wrote:
> > 
> > VMStateDescription vmstate_pit = {
> >     .name = "i8254",
> >     .version_id = 3,
> >     .minimum_version_id = 2,
> >     .minimum_version_id_old = 1,
> >     .load_state_old = pit_load_old,
> >     .fields      = (VMStateField []) {
> > <<<<<<< HEAD
> >         VMSTATE_UINT32(flags, PITState),
> > ||||||| merged common ancestors
> > =======
> >         VMSTATE_UINT32_V(channels[0].irq_disabled, PITState, 3),
> >>>>>>>> ce967e2f33861b0e17753f97fa4527b5943c94b6
> >         VMSTATE_STRUCT_ARRAY(channels, PITState, 3, 2,
> > vmstate_pit_channel, PITChannelState),
> >         VMSTATE_TIMER(channels[0].irq_timer, PITState),
> >         VMSTATE_END_OF_LIST()
> >     }
> > };
> > 
> > I'm guessing that flags and irq_disabled are equivalent, but do they
> > have the same sense (that is, do the "1" values have the same meaning)? 
>
> Yes. qemu-kvm sets flags to 0 or PIT_FLAGS_HPET_LEGACY, which is 1. And
> the latter means "irq_disabled".
>
> > If not, we have a migration problem.
> > 
> > Is it save to just adopt the new version and drop the old one?
>
> The new upstream code was designed to match qemu-kvm's migration format,
> so you can switch. 

Not entirely unexpected, but I wanted to make sure.

> Of course, the result needs a careful check.
>

Thanks!

-- 
error compiling committee.c: too many arguments to function

Re: Reconciling qemu-kvm and qemu's PIT

[Avi Kivity]

On 02/28/2012 04:42 PM, Avi Kivity wrote:

<snip>

I'm getting a crash now:

#0  0x00007ffff4ea0285 in raise    () from /lib64/libc.so.6
#1  0x00007ffff4ea1b9b in abort    () from /lib64/libc.so.6
#2  0x00007ffff4e98e9e in __assert_fail_base ()    from /lib64/libc.so.6
#3  0x00007ffff4e98f42 in __assert_fail    () from /lib64/libc.so.6
#4  0x000055555571c69b in qdev_connect_gpio_out    (dev=0x555556913a70,
n=0, pin=0x5555568ef770) at /home/tlv/akivity/qemu/hw/qdev.c:297
#5  0x000055555582beae in pit_init (bus=0x5555568d5610,    base=64,
isa_irq=-1, alt_irq=0x5555568ef770) at /home/tlv/akivity/qemu/hw/i8254.h:85
#6  0x000055555582ebbc in pc_basic_device_init
(isa_bus=0x5555568d5610,    gsi=0x5555568cadb0,
rtc_state=0x7fffffffdea0, floppy=0x7fffffffdea8, no_vmport=false)
    at /home/tlv/akivity/qemu/hw/pc.c:1182
#7  0x000055555582f454 in pc_init1 (system_memory=0x55555646f270,
system_io=0x55555646f360, ram_size=1073741824,
boot_device=0x7fffffffe300 "cad", kernel_filename=0x0,   
    kernel_cmdline=0x5555558baa12 "", initrd_filename=0x0,
cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1) at
/home/tlv/akivity/qemu/hw/pc_piix.c:256
#8  0x000055555582f8d7 in pc_init_pci (ram_size=1073741824,
boot_device=0x7fffffffe300 "cad", kernel_filename=0x0,
kernel_cmdline=0x5555558baa12 "", initrd_filename=0x0,
    cpu_model=0x0) at /home/tlv/akivity/qemu/hw/pc_piix.c:335
#9  0x00005555556f1349 in main (argc=6,    argv=0x7fffffffe428,
envp=0x7fffffffe460) at /home/tlv/akivity/qemu/vl.c:3431

Looks like isa-pit has zero gpio pins, so it fails when crashing.  I
must have mismerged it, but where is the gpio pin count set?


-- 
error compiling committee.c: too many arguments to function

Re: Reconciling qemu-kvm and qemu's PIT

[Jan Kiszka]

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

On 2012-02-28 20:50, Avi Kivity wrote:
> On 02/28/2012 04:42 PM, Avi Kivity wrote:
> 
> <snip>
> 
> I'm getting a crash now:
> 
> #0  0x00007ffff4ea0285 in raise    () from /lib64/libc.so.6
> #1  0x00007ffff4ea1b9b in abort    () from /lib64/libc.so.6
> #2  0x00007ffff4e98e9e in __assert_fail_base ()    from /lib64/libc.so.6
> #3  0x00007ffff4e98f42 in __assert_fail    () from /lib64/libc.so.6
> #4  0x000055555571c69b in qdev_connect_gpio_out    (dev=0x555556913a70,
> n=0, pin=0x5555568ef770) at /home/tlv/akivity/qemu/hw/qdev.c:297
> #5  0x000055555582beae in pit_init (bus=0x5555568d5610,    base=64,
> isa_irq=-1, alt_irq=0x5555568ef770) at /home/tlv/akivity/qemu/hw/i8254.h:85
> #6  0x000055555582ebbc in pc_basic_device_init
> (isa_bus=0x5555568d5610,    gsi=0x5555568cadb0,
> rtc_state=0x7fffffffdea0, floppy=0x7fffffffdea8, no_vmport=false)
>     at /home/tlv/akivity/qemu/hw/pc.c:1182
> #7  0x000055555582f454 in pc_init1 (system_memory=0x55555646f270,
> system_io=0x55555646f360, ram_size=1073741824,
> boot_device=0x7fffffffe300 "cad", kernel_filename=0x0,   
>     kernel_cmdline=0x5555558baa12 "", initrd_filename=0x0,
> cpu_model=0x0, pci_enabled=1, kvmclock_enabled=1) at
> /home/tlv/akivity/qemu/hw/pc_piix.c:256
> #8  0x000055555582f8d7 in pc_init_pci (ram_size=1073741824,
> boot_device=0x7fffffffe300 "cad", kernel_filename=0x0,
> kernel_cmdline=0x5555558baa12 "", initrd_filename=0x0,
>     cpu_model=0x0) at /home/tlv/akivity/qemu/hw/pc_piix.c:335
> #9  0x00005555556f1349 in main (argc=6,    argv=0x7fffffffe428,
> envp=0x7fffffffe460) at /home/tlv/akivity/qemu/vl.c:3431
> 
> Looks like isa-pit has zero gpio pins, so it fails when crashing.  I
> must have mismerged it, but where is the gpio pin count set?

In pit_initfn. Does -no-kvm-irqchip work fine? It's a bit tricky to
discuss this without seeing your code.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Reconciling qemu-kvm and qemu's PIT

[Avi Kivity]

On 02/28/2012 11:47 PM, Jan Kiszka wrote:
> > 
> > Looks like isa-pit has zero gpio pins, so it fails when crashing.  I
> > must have mismerged it, but where is the gpio pin count set?
>
> In pit_initfn. Does -no-kvm-irqchip work fine? It's a bit tricky to
> discuss this without seeing your code.
>

pushed it into qemu-kvm.git usptream-merge

-- 
error compiling committee.c: too many arguments to function

Re: Reconciling qemu-kvm and qemu's PIT

[Jan Kiszka]

On 2012-02-29 10:29, Avi Kivity wrote:
> On 02/28/2012 11:47 PM, Jan Kiszka wrote:
>>>
>>> Looks like isa-pit has zero gpio pins, so it fails when crashing.  I
>>> must have mismerged it, but where is the gpio pin count set?
>>
>> In pit_initfn. Does -no-kvm-irqchip work fine? It's a bit tricky to
>> discuss this without seeing your code.
>>
> 
> pushed it into qemu-kvm.git usptream-merge
> 

As I assumed: You try to initialize the kvm-pit like the userspace pit,
that cannot work. Don't run the qdev_connect_gpio_out in pit_init, just
like my kvm-pit patches does in their kvm_pit_init.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Reconciling qemu-kvm and qemu's PIT

[Avi Kivity]

On 02/29/2012 12:14 PM, Jan Kiszka wrote:
> On 2012-02-29 10:29, Avi Kivity wrote:
> > On 02/28/2012 11:47 PM, Jan Kiszka wrote:
> >>>
> >>> Looks like isa-pit has zero gpio pins, so it fails when crashing.  I
> >>> must have mismerged it, but where is the gpio pin count set?
> >>
> >> In pit_initfn. Does -no-kvm-irqchip work fine? It's a bit tricky to
> >> discuss this without seeing your code.
> >>
> > 
> > pushed it into qemu-kvm.git usptream-merge
> > 
>
> As I assumed: You try to initialize the kvm-pit like the userspace pit,
> that cannot work. Don't run the qdev_connect_gpio_out in pit_init, just
> like my kvm-pit patches does in their kvm_pit_init.
>

The merge is now in 'next', hopefully not too many regressions.

-- 
error compiling committee.c: too many arguments to function

Re: Reconciling qemu-kvm and qemu's PIT

[Jan Kiszka]

On 2012-02-29 14:45, Avi Kivity wrote:
> On 02/29/2012 12:14 PM, Jan Kiszka wrote:
>> On 2012-02-29 10:29, Avi Kivity wrote:
>>> On 02/28/2012 11:47 PM, Jan Kiszka wrote:
>>>>>
>>>>> Looks like isa-pit has zero gpio pins, so it fails when crashing.  I
>>>>> must have mismerged it, but where is the gpio pin count set?
>>>>
>>>> In pit_initfn. Does -no-kvm-irqchip work fine? It's a bit tricky to
>>>> discuss this without seeing your code.
>>>>
>>>
>>> pushed it into qemu-kvm.git usptream-merge
>>>
>>
>> As I assumed: You try to initialize the kvm-pit like the userspace pit,
>> that cannot work. Don't run the qdev_connect_gpio_out in pit_init, just
>> like my kvm-pit patches does in their kvm_pit_init.
>>
> 
> The merge is now in 'next', hopefully not too many regressions.

Hope we can quickly finish the switch to the new kvm-pit.

When do you plan to push or rebase uq/master? Then I could check/refresh
my kvm-pit series on top of it.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: Reconciling qemu-kvm and qemu's PIT

[Avi Kivity]

On 02/29/2012 04:24 PM, Jan Kiszka wrote:
> On 2012-02-29 14:45, Avi Kivity wrote:
> > On 02/29/2012 12:14 PM, Jan Kiszka wrote:
> >> On 2012-02-29 10:29, Avi Kivity wrote:
> >>> On 02/28/2012 11:47 PM, Jan Kiszka wrote:
> >>>>>
> >>>>> Looks like isa-pit has zero gpio pins, so it fails when crashing.  I
> >>>>> must have mismerged it, but where is the gpio pin count set?
> >>>>
> >>>> In pit_initfn. Does -no-kvm-irqchip work fine? It's a bit tricky to
> >>>> discuss this without seeing your code.
> >>>>
> >>>
> >>> pushed it into qemu-kvm.git usptream-merge
> >>>
> >>
> >> As I assumed: You try to initialize the kvm-pit like the userspace pit,
> >> that cannot work. Don't run the qdev_connect_gpio_out in pit_init, just
> >> like my kvm-pit patches does in their kvm_pit_init.
> >>
> > 
> > The merge is now in 'next', hopefully not too many regressions.
>
> Hope we can quickly finish the switch to the new kvm-pit.
>
> When do you plan to push or rebase uq/master? Then I could check/refresh
> my kvm-pit series on top of it.

Real soon... I hoped to do it after the upstream merge, but it doesn't
pass autotest due to a screendump regression.

-- 
error compiling committee.c: too many arguments to function