[Qemu-devel] Merging kvm-apic into qemu-kvm

[Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

The changes to kvm-apic are so drastic, that merging them into qemu-kvm
in the normal way won't work.  I can consider just dropping the existing
implementation and switching to the new one, but the comment at the end

    Make the basic in-kernel irqchip support selectable via
    -machine ...,kernel_irqchip=on. Leave it off by default until it can
    fully replace user space models.

suggests that things are still missing.

Jan, what's still missing?  Any idea on how to proceed?

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

On 2012-01-26 16:15, Avi Kivity wrote:
> The changes to kvm-apic are so drastic, that merging them into qemu-kvm
> in the normal way won't work.  I can consider just dropping the existing
> implementation and switching to the new one, but the comment at the end
> 
>     Make the basic in-kernel irqchip support selectable via
>     -machine ...,kernel_irqchip=on. Leave it off by default until it can
>     fully replace user space models.
> 
> suggests that things are still missing.
> 
> Jan, what's still missing?

- in-kernel PIT (patches done, waiting for some upstream bits to be
  merged first)
- TPR acceleration via VAPIC (WIP)
- MSI support

The latter is the big chunk. It requires quite some
refactoring/enhancement of the MSI layer. I posted the first version
last year. We need to agree on the design, then probably switch qemu-kvm
over while pushing generic bits upstream. And then we can extend the
upstream in-kernel *PIC using that new interfaces. Once upstream works
with MSI, we can switch qemu-kvm over, leaving basically only
device-assignment as the last missing bit.

>  Any idea on how to proceed?

I had a qemu-kvm branch here that disables the upstream in-kernel *PIC
in favor of its current version. I still need to refresh that work (was
based on an earlier revision), but it was not that horrible. Let me check...

Jan

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

On 2012-01-26 16:25, Jan Kiszka wrote:
> On 2012-01-26 16:15, Avi Kivity wrote:
>> The changes to kvm-apic are so drastic, that merging them into qemu-kvm
>> in the normal way won't work.  I can consider just dropping the existing
>> implementation and switching to the new one, but the comment at the end
>>
>>     Make the basic in-kernel irqchip support selectable via
>>     -machine ...,kernel_irqchip=on. Leave it off by default until it can
>>     fully replace user space models.
>>
>> suggests that things are still missing.
>>
>> Jan, what's still missing?
> 
> - in-kernel PIT (patches done, waiting for some upstream bits to be
>   merged first)
> - TPR acceleration via VAPIC (WIP)
> - MSI support
> 
> The latter is the big chunk. It requires quite some
> refactoring/enhancement of the MSI layer. I posted the first version
> last year. We need to agree on the design, then probably switch qemu-kvm
> over while pushing generic bits upstream. And then we can extend the
> upstream in-kernel *PIC using that new interfaces. Once upstream works
> with MSI, we can switch qemu-kvm over, leaving basically only
> device-assignment as the last missing bit.
> 
>>  Any idea on how to proceed?
> 
> I had a qemu-kvm branch here that disables the upstream in-kernel *PIC
> in favor of its current version. I still need to refresh that work (was
> based on an earlier revision), but it was not that horrible. Let me check...

It's online, see
http://git.kiszka.org/?p=qemu-kvm.git;a=shortlog;h=refs/heads/kvm-irqchip-merge

I merged the upstream patches one by one, resolving the mechanical and
logical conflicts in each step. Was done for that backend/frontend
concept, but the adjustments should basically be the same now. Want me
to prepare a branch or will you do this?

Jan

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/26/2012 05:32 PM, Jan Kiszka wrote:
> On 2012-01-26 16:25, Jan Kiszka wrote:
> > On 2012-01-26 16:15, Avi Kivity wrote:
> >> The changes to kvm-apic are so drastic, that merging them into qemu-kvm
> >> in the normal way won't work.  I can consider just dropping the existing
> >> implementation and switching to the new one, but the comment at the end
> >>
> >>     Make the basic in-kernel irqchip support selectable via
> >>     -machine ...,kernel_irqchip=on. Leave it off by default until it can
> >>     fully replace user space models.
> >>
> >> suggests that things are still missing.
> >>
> >> Jan, what's still missing?
> > 
> > - in-kernel PIT (patches done, waiting for some upstream bits to be
> >   merged first)
> > - TPR acceleration via VAPIC (WIP)
> > - MSI support
> > 
> > The latter is the big chunk. It requires quite some
> > refactoring/enhancement of the MSI layer. I posted the first version
> > last year. We need to agree on the design, then probably switch qemu-kvm
> > over while pushing generic bits upstream. And then we can extend the
> > upstream in-kernel *PIC using that new interfaces. Once upstream works
> > with MSI, we can switch qemu-kvm over, leaving basically only
> > device-assignment as the last missing bit.
> > 
> >>  Any idea on how to proceed?
> > 
> > I had a qemu-kvm branch here that disables the upstream in-kernel *PIC
> > in favor of its current version. I still need to refresh that work (was
> > based on an earlier revision), but it was not that horrible. Let me check...
>
> It's online, see
> http://git.kiszka.org/?p=qemu-kvm.git;a=shortlog;h=refs/heads/kvm-irqchip-merge

You're a hero.

> I merged the upstream patches one by one, resolving the mechanical and
> logical conflicts in each step. Was done for that backend/frontend
> concept, but the adjustments should basically be the same now. Want me
> to prepare a branch or will you do this?

It's much more likely that you'll get it right - I started to do this
but backed out.

btw, the branch doesn't appear to be merges, so I'll still have huge
conflicts at the end.  If you do this with real merges, git will
recognize it and just adopt your version.

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

On 2012-01-26 16:39, Avi Kivity wrote:
> On 01/26/2012 05:32 PM, Jan Kiszka wrote:
>> On 2012-01-26 16:25, Jan Kiszka wrote:
>>> On 2012-01-26 16:15, Avi Kivity wrote:
>>>> The changes to kvm-apic are so drastic, that merging them into qemu-kvm
>>>> in the normal way won't work.  I can consider just dropping the existing
>>>> implementation and switching to the new one, but the comment at the end
>>>>
>>>>     Make the basic in-kernel irqchip support selectable via
>>>>     -machine ...,kernel_irqchip=on. Leave it off by default until it can
>>>>     fully replace user space models.
>>>>
>>>> suggests that things are still missing.
>>>>
>>>> Jan, what's still missing?
>>>
>>> - in-kernel PIT (patches done, waiting for some upstream bits to be
>>>   merged first)
>>> - TPR acceleration via VAPIC (WIP)
>>> - MSI support
>>>
>>> The latter is the big chunk. It requires quite some
>>> refactoring/enhancement of the MSI layer. I posted the first version
>>> last year. We need to agree on the design, then probably switch qemu-kvm
>>> over while pushing generic bits upstream. And then we can extend the
>>> upstream in-kernel *PIC using that new interfaces. Once upstream works
>>> with MSI, we can switch qemu-kvm over, leaving basically only
>>> device-assignment as the last missing bit.
>>>
>>>>  Any idea on how to proceed?
>>>
>>> I had a qemu-kvm branch here that disables the upstream in-kernel *PIC
>>> in favor of its current version. I still need to refresh that work (was
>>> based on an earlier revision), but it was not that horrible. Let me check...
>>
>> It's online, see
>> http://git.kiszka.org/?p=qemu-kvm.git;a=shortlog;h=refs/heads/kvm-irqchip-merge
> 
> You're a hero.
> 
>> I merged the upstream patches one by one, resolving the mechanical and
>> logical conflicts in each step. Was done for that backend/frontend
>> concept, but the adjustments should basically be the same now. Want me
>> to prepare a branch or will you do this?
> 
> It's much more likely that you'll get it right - I started to do this
> but backed out.
> 
> btw, the branch doesn't appear to be merges, so I'll still have huge
> conflicts at the end.  If you do this with real merges, git will
> recognize it and just adopt your version.

I will try to use your concept: pull in upstream commits into a merge
branch as long as there is a mechanical or logical conflict. Will then
publish the branch for pulling. Can I start at the current 'next' head?

Jan

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/26/2012 05:45 PM, Jan Kiszka wrote:
> > 
> >> I merged the upstream patches one by one, resolving the mechanical and
> >> logical conflicts in each step. Was done for that backend/frontend
> >> concept, but the adjustments should basically be the same now. Want me
> >> to prepare a branch or will you do this?
> > 
> > It's much more likely that you'll get it right - I started to do this
> > but backed out.
> > 
> > btw, the branch doesn't appear to be merges, so I'll still have huge
> > conflicts at the end.  If you do this with real merges, git will
> > recognize it and just adopt your version.
>
> I will try to use your concept: pull in upstream commits into a merge
> branch as long as there is a mechanical or logical conflict. 

That's what I do in my upstream merges.  I use bisect to find the first
conflict, but in this case I imagine there will be a conflict in every
merge except the memory.c one.

> Will then
> publish the branch for pulling. Can I start at the current 'next' head?

Yes please.  It's halfway through autotest and looks good.  Even if I
have to change it, we can 'git rebase -p --onto' your branch (though I
doubt it will be necessary).

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

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

On 2012-01-26 16:49, Avi Kivity wrote:
> On 01/26/2012 05:45 PM, Jan Kiszka wrote:
>>>
>>>> I merged the upstream patches one by one, resolving the mechanical and
>>>> logical conflicts in each step. Was done for that backend/frontend
>>>> concept, but the adjustments should basically be the same now. Want me
>>>> to prepare a branch or will you do this?
>>>
>>> It's much more likely that you'll get it right - I started to do this
>>> but backed out.
>>>
>>> btw, the branch doesn't appear to be merges, so I'll still have huge
>>> conflicts at the end.  If you do this with real merges, git will
>>> recognize it and just adopt your version.
>>
>> I will try to use your concept: pull in upstream commits into a merge
>> branch as long as there is a mechanical or logical conflict. 
> 
> That's what I do in my upstream merges.  I use bisect to find the first
> conflict, but in this case I imagine there will be a conflict in every
> merge except the memory.c one.
> 
>> Will then
>> publish the branch for pulling. Can I start at the current 'next' head?
> 
> Yes please.  It's halfway through autotest and looks good.  Even if I
> have to change it, we can 'git rebase -p --onto' your branch (though I
> doubt it will be necessary).

Done, see

git://git.kiszka.org/qemu-kvm.git queues/qemu-merge

Only moderately tested so far, I'm counting on your machinery.

Jan


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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/27/2012 11:34 PM, Jan Kiszka wrote:
> > 
> > Yes please.  It's halfway through autotest and looks good.  Even if I
> > have to change it, we can 'git rebase -p --onto' your branch (though I
> > doubt it will be necessary).
>
> Done, see
>
> git://git.kiszka.org/qemu-kvm.git queues/qemu-merge
>
> Only moderately tested so far, I'm counting on your machinery.
>

Pulled, thanks a lot.  Testing now.

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/29/2012 12:33 PM, Avi Kivity wrote:
> On 01/27/2012 11:34 PM, Jan Kiszka wrote:
> > > 
> > > Yes please.  It's halfway through autotest and looks good.  Even if I
> > > have to change it, we can 'git rebase -p --onto' your branch (though I
> > > doubt it will be necessary).
> >
> > Done, see
> >
> > git://git.kiszka.org/qemu-kvm.git queues/qemu-merge
> >
> > Only moderately tested so far, I'm counting on your machinery.
> >
>
> Pulled, thanks a lot.  Testing now.
>

1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see
the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. 
Something's wrong.

2. Migration is broken.

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

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

On 2012-01-29 12:12, Avi Kivity wrote:
> On 01/29/2012 12:33 PM, Avi Kivity wrote:
>> On 01/27/2012 11:34 PM, Jan Kiszka wrote:
>>>>
>>>> Yes please.  It's halfway through autotest and looks good.  Even if I
>>>> have to change it, we can 'git rebase -p --onto' your branch (though I
>>>> doubt it will be necessary).
>>>
>>> Done, see
>>>
>>> git://git.kiszka.org/qemu-kvm.git queues/qemu-merge
>>>
>>> Only moderately tested so far, I'm counting on your machinery.
>>>
>>
>> Pulled, thanks a lot.  Testing now.
>>
> 
> 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see
> the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. 
> Something's wrong.

Nope, that's just the behavior of the original qemu-kvm irqchip (i.e.
kvm extension is merged into the emulated device). Nothing changed here
so far.

> 
> 2. Migration is broken.

OK, that's new. A trivial scenario?

Jan


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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/29/2012 01:15 PM, Jan Kiszka wrote:
> On 2012-01-29 12:12, Avi Kivity wrote:
> > On 01/29/2012 12:33 PM, Avi Kivity wrote:
> >> On 01/27/2012 11:34 PM, Jan Kiszka wrote:
> >>>>
> >>>> Yes please.  It's halfway through autotest and looks good.  Even if I
> >>>> have to change it, we can 'git rebase -p --onto' your branch (though I
> >>>> doubt it will be necessary).
> >>>
> >>> Done, see
> >>>
> >>> git://git.kiszka.org/qemu-kvm.git queues/qemu-merge
> >>>
> >>> Only moderately tested so far, I'm counting on your machinery.
> >>>
> >>
> >> Pulled, thanks a lot.  Testing now.
> >>
> > 
> > 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see
> > the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. 
> > Something's wrong.
>
> Nope, that's just the behavior of the original qemu-kvm irqchip (i.e.
> kvm extension is merged into the emulated device). Nothing changed here
> so far.

So, -no-kvm-irqchip should still work as expected?

>
> > 
> > 2. Migration is broken.
>
> OK, that's new. A trivial scenario?
>

Incoming command line:

  qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming tcp::4444

I expect you can remove '-smp 2' and it would still fail.

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

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

On 2012-01-29 12:18, Avi Kivity wrote:
> On 01/29/2012 01:15 PM, Jan Kiszka wrote:
>> On 2012-01-29 12:12, Avi Kivity wrote:
>>> On 01/29/2012 12:33 PM, Avi Kivity wrote:
>>>> On 01/27/2012 11:34 PM, Jan Kiszka wrote:
>>>>>>
>>>>>> Yes please.  It's halfway through autotest and looks good.  Even if I
>>>>>> have to change it, we can 'git rebase -p --onto' your branch (though I
>>>>>> doubt it will be necessary).
>>>>>
>>>>> Done, see
>>>>>
>>>>> git://git.kiszka.org/qemu-kvm.git queues/qemu-merge
>>>>>
>>>>> Only moderately tested so far, I'm counting on your machinery.
>>>>>
>>>>
>>>> Pulled, thanks a lot.  Testing now.
>>>>
>>>
>>> 1. The default shows apic/ioapic in 'info qtree' (no kvm-), yet I see
>>> the vcpu threads in kvm_vcpu_block(), implying in-kernel irqchip. 
>>> Something's wrong.
>>
>> Nope, that's just the behavior of the original qemu-kvm irqchip (i.e.
>> kvm extension is merged into the emulated device). Nothing changed here
>> so far.
> 
> So, -no-kvm-irqchip should still work as expected?

Yes. In addition, I've patches here to make -machine kernel_irqchip=off
work as well.

> 
>>
>>>
>>> 2. Migration is broken.
>>
>> OK, that's new. A trivial scenario?
>>
> 
> Incoming command line:
> 
>   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
> -incoming tcp::4444
> 
> I expect you can remove '-smp 2' and it would still fail.
> 

Will check.

Jan


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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

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

On 2012-01-29 12:18, Avi Kivity wrote:
>>>
>>> 2. Migration is broken.
>>
>> OK, that's new. A trivial scenario?
>>
> 
> Incoming command line:
> 
>   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
> -incoming tcp::4444
> 
> I expect you can remove '-smp 2' and it would still fail.
> 

Could you check if merge point 5fc4ecdf10 works for you? For me it does,
and b1b774ba43 starts failing. Given that the screen is corrupted on the
target side, I suspect the cirrus hwlib moving may have an influence.

Jan


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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/29/2012 01:54 PM, Jan Kiszka wrote:
> On 2012-01-29 12:18, Avi Kivity wrote:
> >>>
> >>> 2. Migration is broken.
> >>
> >> OK, that's new. A trivial scenario?
> >>
> > 
> > Incoming command line:
> > 
> >   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
> > -incoming tcp::4444
> > 
> > I expect you can remove '-smp 2' and it would still fail.
> > 
>
> Could you check if merge point 5fc4ecdf10 works for you? For me it does,
> and b1b774ba43 starts failing. Given that the screen is corrupted on the
> target side, I suspect the cirrus hwlib moving may have an influence.
>

It does, and I see the screen corruption as well (on the HEAD of the
merge, not 5fc4).

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Jan Kiszka]

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

On 2012-01-29 13:01, Avi Kivity wrote:
> On 01/29/2012 01:54 PM, Jan Kiszka wrote:
>> On 2012-01-29 12:18, Avi Kivity wrote:
>>>>>
>>>>> 2. Migration is broken.
>>>>
>>>> OK, that's new. A trivial scenario?
>>>>
>>>
>>> Incoming command line:
>>>
>>>   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
>>> -incoming tcp::4444
>>>
>>> I expect you can remove '-smp 2' and it would still fail.
>>>
>>
>> Could you check if merge point 5fc4ecdf10 works for you? For me it does,
>> and b1b774ba43 starts failing. Given that the screen is corrupted on the
>> target side, I suspect the cirrus hwlib moving may have an influence.
>>
> 
> It does, and I see the screen corruption as well (on the HEAD of the
> merge, not 5fc4).

Looks like 59abb06198 (memory: fix dirty mask function length handling)
is causing this. Might be visible with upstream as well then. Any idea?

Jan


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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/29/2012 02:02 PM, Jan Kiszka wrote:
> On 2012-01-29 13:01, Avi Kivity wrote:
> > On 01/29/2012 01:54 PM, Jan Kiszka wrote:
> >> On 2012-01-29 12:18, Avi Kivity wrote:
> >>>>>
> >>>>> 2. Migration is broken.
> >>>>
> >>>> OK, that's new. A trivial scenario?
> >>>>
> >>>
> >>> Incoming command line:
> >>>
> >>>   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
> >>> -incoming tcp::4444
> >>>
> >>> I expect you can remove '-smp 2' and it would still fail.
> >>>
> >>
> >> Could you check if merge point 5fc4ecdf10 works for you? For me it does,
> >> and b1b774ba43 starts failing. Given that the screen is corrupted on the
> >> target side, I suspect the cirrus hwlib moving may have an influence.
> >>
> > 
> > It does, and I see the screen corruption as well (on the HEAD of the
> > merge, not 5fc4).
>
> Looks like 59abb06198 (memory: fix dirty mask function length handling)
> is causing this. Might be visible with upstream as well then. Any idea?
>

Blue posted patches for this.  s/<=/</ is the simplest.

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/29/2012 02:04 PM, Avi Kivity wrote:
> On 01/29/2012 02:02 PM, Jan Kiszka wrote:
> > On 2012-01-29 13:01, Avi Kivity wrote:
> > > On 01/29/2012 01:54 PM, Jan Kiszka wrote:
> > >> On 2012-01-29 12:18, Avi Kivity wrote:
> > >>>>>
> > >>>>> 2. Migration is broken.
> > >>>>
> > >>>> OK, that's new. A trivial scenario?
> > >>>>
> > >>>
> > >>> Incoming command line:
> > >>>
> > >>>   qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
> > >>> -incoming tcp::4444
> > >>>
> > >>> I expect you can remove '-smp 2' and it would still fail.
> > >>>
> > >>
> > >> Could you check if merge point 5fc4ecdf10 works for you? For me it does,
> > >> and b1b774ba43 starts failing. Given that the screen is corrupted on the
> > >> target side, I suspect the cirrus hwlib moving may have an influence.
> > >>
> > > 
> > > It does, and I see the screen corruption as well (on the HEAD of the
> > > merge, not 5fc4).
> >
> > Looks like 59abb06198 (memory: fix dirty mask function length handling)
> > is causing this. Might be visible with upstream as well then. Any idea?
> >
>
> Blue posted patches for this.  s/<=/</ is the simplest.
>

Err, not.  I'll just try Blue's patch.

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/29/2012 02:06 PM, Avi Kivity wrote:
> >
> > Blue posted patches for this.  s/<=/</ is the simplest.
> >
>
> Err, not.  I'll just try Blue's patch.
>

With a fix, migration doesn't complete.  Looking into it.

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

Re: [Qemu-devel] Merging kvm-apic into qemu-kvm

[Avi Kivity]

On 01/29/2012 02:35 PM, Avi Kivity wrote:
> On 01/29/2012 02:06 PM, Avi Kivity wrote:
> > >
> > > Blue posted patches for this.  s/<=/</ is the simplest.
> > >
> >
> > Err, not.  I'll just try Blue's patch.
> >
>
> With a fix, migration doesn't complete.  Looking into it.
>

Turns out the migration problems are unrelated, and are descendents of
the apic merge, so I merged just that.  I'll look at the migration
problems now.

Thanks again!

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