Re: Merging kvm-apic into qemu-kvm
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/<=/ > > > > > > 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 -- 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: Merging kvm-apic into qemu-kvm
On 01/29/2012 02:06 PM, Avi Kivity wrote: > > > > Blue posted patches for this. s/<=/ > > > 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 -- 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: Merging kvm-apic into qemu-kvm
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:: > > >>> > > >>> 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/<=/ Err, not. I'll just try Blue's patch. -- 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: Merging kvm-apic into qemu-kvm
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:: > >>> > >>> 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/<=/http://vger.kernel.org/majordomo-info.html
Re: Merging kvm-apic into qemu-kvm
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:: >>> >>> 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 signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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:: > > > > 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 -- 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: Merging kvm-apic into qemu-kvm
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:: > > 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 signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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:: > > I expect you can remove '-smp 2' and it would still fail. > Will check. Jan signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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:: I expect you can remove '-smp 2' and it would still fail. -- 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: Merging kvm-apic into qemu-kvm
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 signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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 -- 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: Merging kvm-apic into qemu-kvm
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 -- 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: Merging kvm-apic into qemu-kvm
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 signature.asc Description: OpenPGP digital signature
Re: Merging kvm-apic into qemu-kvm
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 -- 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: Merging kvm-apic into qemu-kvm
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 -- 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: Merging kvm-apic into qemu-kvm
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 -- 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: Merging kvm-apic into qemu-kvm
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 -- 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: Merging kvm-apic into qemu-kvm
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 -- 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
