Merging kvm-apic into qemu-kvm
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?
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 11 lines · 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?
- 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.
Quoted 1 line
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 26 lines · Jan Kiszka
Quoted 11 lines · 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?
- in-kernel PIT (patches done, waiting for some upstream bits to be merged first)
- TPR acceleration via VAPIC (WIP)
- MSI supportThe 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.
Quoted 5 lines
Quoted 1 line
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 27 lines · Jan Kiszka
Quoted 26 lines · Jan Kiszka
Quoted 11 lines · 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?
- in-kernel PIT (patches done, waiting for some upstream bits to be merged first)
- TPR acceleration via VAPIC (WIP)
- MSI supportThe 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.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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.
Quoted 4 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 44 lines · Avi Kivity
Quoted 27 lines · Jan Kiszka
Quoted 26 lines · Jan Kiszka
Quoted 11 lines · 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?
- in-kernel PIT (patches done, waiting for some upstream bits to be merged first)
- TPR acceleration via VAPIC (WIP)
- MSI supportThe 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.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
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-mergeYou're a hero.
Quoted 4 lines
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?
Quoted 6 lines
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
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Quoted 9 lines · Jan Kiszka
Quoted 9 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 2 lines
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).
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 21 lines · Avi Kivity
Quoted 9 lines · Jan Kiszka
Quoted 9 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 3 lines
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.cone.
Quoted 6 lines
Quoted 2 lines
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
Quoted 11 lines · Jan Kiszka
Quoted 4 lines
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.gitqueues/qemu-mergeOnly moderately tested so far, I'm counting on your machinery.
Pulled, thanks a lot. Testing now.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 6 lines · Avi Kivity
Quoted 5 lines · Jan Kiszka
Quoted 4 lines
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).
Quoted 9 lines
Quoted 6 lines
Done, see
git://git.kiszka.org/qemu-kvm.gitqueues/qemu-mergeOnly 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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 14 lines · Avi Kivity
Quoted 13 lines · Avi Kivity
Quoted 11 lines · Jan Kiszka
Quoted 4 lines
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.gitqueues/qemu-mergeOnly moderately tested so far, I'm counting on your machinery.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 2 lines
2. Migration is broken.
OK, that's new. A trivial scenario?
Jan
Quoted 18 lines · Jan Kiszka
Quoted 17 lines · Avi Kivity
Quoted 15 lines · Avi Kivity
Quoted 11 lines · Jan Kiszka
Quoted 4 lines
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.gitqueues/qemu-mergeOnly moderately tested so far, I'm counting on your machinery.
Pulled, thanks a lot. Testing now.
Quoted 7 lines
Quoted 3 lines
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?
Quoted 6 lines
Quoted 3 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 23 lines · Avi Kivity
Quoted 22 lines · Jan Kiszka
Quoted 20 lines · Avi Kivity
Quoted 6 lines · Avi Kivity
Quoted 5 lines · Jan Kiszka
Quoted 4 lines
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).
Quoted 9 lines
Quoted 6 lines
Done, see
git://git.kiszka.org/qemu-kvm.gitqueues/qemu-mergeOnly 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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
2. Migration is broken.
OK, that's new. A trivial scenario?
Quoted 7 lines
Incoming command line:
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming tcp::4444I expect you can remove '-smp 2' and it would still fail.
Will check.
Jan
Quoted 6 lines · Avi Kivity
Quoted 5 lines
Quoted 2 lines
2. Migration is broken.
OK, that's new. A trivial scenario?
Quoted 7 lines
Incoming command line:
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming tcp::4444I 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
Quoted 12 lines · Jan Kiszka
Quoted 11 lines · Avi Kivity
Quoted 5 lines
Quoted 2 lines
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
Quoted 7 lines
Quoted 2 lines
I expect you can remove '-smp 2' and it would still fail.
Could you check if merge point
5fc4ecdf10works for you? For me it does, andb1b774ba43starts 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).
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 16 lines · Avi Kivity
Quoted 15 lines · Jan Kiszka
Quoted 13 lines · Avi Kivity
Quoted 5 lines
Quoted 2 lines
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::4444I expect you can remove '-smp 2' and it would still fail.
Quoted 7 lines
Quoted 4 lines
Could you check if merge point
5fc4ecdf10works for you? For me it does, andb1b774ba43starts 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
Quoted 22 lines · Jan Kiszka
Quoted 21 lines · Avi Kivity
Quoted 19 lines · Jan Kiszka
Quoted 6 lines · Avi Kivity
Quoted 5 lines
Quoted 2 lines
2. Migration is broken.
OK, that's new. A trivial scenario?
Quoted 7 lines
Incoming command line:
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming tcp::4444I expect you can remove '-smp 2' and it would still fail.
Could you check if merge point
5fc4ecdf10works for you? For me it does, andb1b774ba43starts failing. Given that the screen is corrupted on the target side, I suspect the cirrus hwlib moving may have an influence.
Quoted 6 lines
Quoted 2 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 23 lines · Avi Kivity
Quoted 22 lines · Jan Kiszka
Quoted 21 lines · Avi Kivity
Quoted 19 lines · Jan Kiszka
Quoted 6 lines · Avi Kivity
Quoted 5 lines
Quoted 2 lines
2. Migration is broken.
OK, that's new. A trivial scenario?
Quoted 7 lines
Incoming command line:
qemu-system-x86_64 -m 512 /images/Fedora.img -smp 2 -monitor stdio
-incoming tcp::4444I expect you can remove '-smp 2' and it would still fail.
Could you check if merge point
5fc4ecdf10works for you? For me it does, andb1b774ba43starts failing. Given that the screen is corrupted on the target side, I suspect the cirrus hwlib moving may have an influence.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 6 lines · Avi Kivity
Quoted 3 lines
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.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 10 lines · Avi Kivity
Quoted 6 lines · Avi Kivity
Quoted 3 lines
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!
Signature · 1 line
error compiling committee.c: too many arguments to function