Re: [Qemu-devel] [PATCH RFC 0/4] vGICv3 support
Hello! > I thought the general sense here was that since emulating the full > device is much more complicated than driving the KVM part, Yes, but still it actually shares 50% of the code with SW emulation. It reuses vGICv3 base class as well as new machine. > the integration with the virt board should go in via this series, and the > emulation should build on top of that? You know... I could rip parts of Shlomo's patches and use them as base for my series. But, does it worth efforts? It will actually be a reposting of the same code over and over again... > It just felt like both patch series have stalled somehow, and I would > like to see what we can do to get this stuff moving again. For this purpose you can talk to Peter i guess, because it was his decision. By the way, when does freeze period end? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
Re: [Qemu-devel] [PATCH RFC 0/4] vGICv3 support
On Wed, Jul 01, 2015 at 02:14:55PM +0300, Pavel Fedin wrote: > Hello! > > > I think it would be good if you could re-spin this series based on > > Eric's comments on the code, my comments on the patch style, and Peter's > > advise on using machine properties for GICv3. > > There was a discussion about this, and i tried to add a machine property > instead. This gave bad > results: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg04842.html > > > Do you have cycles to continue working on this? > > Yes, i do. And i wish to work on this, since upstreaming this is a goal of > my project. > I know that descriptions were bad, and actually they were parts of ongoing > discussions. Actually i > am waiting for integration of Shlomo Pongratz' series: > http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg01512.html. Posted > as standalone, my > series collide with Shlomo's series (it actually relies on some parts from > there), so i prefer to > respin on top of something clean. I thought the general sense here was that since emulating the full device is much more complicated than driving the KVM part, the integration with the virt board should go in via this series, and the emulation should build on top of that? Of course, if the full emulation series is almost ready to be merged that's a different story. It just felt like both patch series have stalled somehow, and I would like to see what we can do to get this stuff moving again. > The first patch from the mentioned series is already in master; Peter told > me that he doesn't want > to add the complete GICv3 before qemu 2.4 is released: > https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg04171.html > So waiting... > Fair enough. -Christoffer
Re: [Qemu-devel] [PATCH RFC 0/4] vGICv3 support
Hello! > I think it would be good if you could re-spin this series based on > Eric's comments on the code, my comments on the patch style, and Peter's > advise on using machine properties for GICv3. There was a discussion about this, and i tried to add a machine property instead. This gave bad results: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg04842.html > Do you have cycles to continue working on this? Yes, i do. And i wish to work on this, since upstreaming this is a goal of my project. I know that descriptions were bad, and actually they were parts of ongoing discussions. Actually i am waiting for integration of Shlomo Pongratz' series: http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg01512.html. Posted as standalone, my series collide with Shlomo's series (it actually relies on some parts from there), so i prefer to respin on top of something clean. The first patch from the mentioned series is already in master; Peter told me that he doesn't want to add the complete GICv3 before qemu 2.4 is released: https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg04171.html So waiting... Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
Re: [Qemu-devel] [PATCH RFC 0/4] vGICv3 support
On Wed, Jul 01, 2015 at 12:21:12PM +0200, Christoffer Dall wrote: > On Fri, May 22, 2015 at 01:58:40PM +0300, Pavel Fedin wrote: > > This is my alternative to Ashok's vGICv3 patch > > (https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg03021.html), which > > i am currently working on. It addresses vGIC capability verification issue > > (kvm_irqchip_create() / kvm_arch_irqchip_create()), as well as offers better > > code structure (v3 code separated from v2). > > This patchset applies on top of this: > > https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00943.html. Note > > that > > GIC type selection still relies on machine name (virt-v3 vs virt), and not > > on > > machine option. Since libvirt has recently introduced support for extra > > options, > > i have absolutely nothing against Ashok's approach. I just did not change > > this > > yet because it would affect my testing environment. The aim of this RFC is > > to > > focus on vGICv3 implementation and related changes. And yes, i agree that > > v2 and > > v3 now have some copypasted code, and this is TBD. > > This cover letter is not really helpful as it only describes the history > and circumstances of how this patch came to be. > > It would be helpful if the beginning of this cover letter focuses on > what the patch series does and which design decisions have been taken to > shape the patches the way they are. > > I don't understand the whole background thing about libvirt and I don't I replied to the earlier posting of the patch series that the quoted libvirt limitation does not exist any longer, so that really should not be mentioned as a problem/rationale for the machine type approach anymore. I agree with Peter GICv3 should be selected based on properties not new machine types. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH RFC 0/4] vGICv3 support
On Fri, May 22, 2015 at 01:58:40PM +0300, Pavel Fedin wrote: > This is my alternative to Ashok's vGICv3 patch > (https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg03021.html), which > i am currently working on. It addresses vGIC capability verification issue > (kvm_irqchip_create() / kvm_arch_irqchip_create()), as well as offers better > code structure (v3 code separated from v2). > This patchset applies on top of this: > https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00943.html. Note that > GIC type selection still relies on machine name (virt-v3 vs virt), and not on > machine option. Since libvirt has recently introduced support for extra > options, > i have absolutely nothing against Ashok's approach. I just did not change this > yet because it would affect my testing environment. The aim of this RFC is to > focus on vGICv3 implementation and related changes. And yes, i agree that v2 > and > v3 now have some copypasted code, and this is TBD. This cover letter is not really helpful as it only describes the history and circumstances of how this patch came to be. It would be helpful if the beginning of this cover letter focuses on what the patch series does and which design decisions have been taken to shape the patches the way they are. I don't understand the whole background thing about libvirt and I don't at all understand the thing about copy-pasted code...?? A generally good approach to writing a cover letter is to follow this skeleton: --- This series implements... We accomplish this by... [Optional] Patches 1-3 , patches 4-8 ... [Optional] Note Changes since vX: --- I think it would be good if you could re-spin this series based on Eric's comments on the code, my comments on the patch style, and Peter's advise on using machine properties for GICv3. Do you have cycles to continue working on this? -Christoffer > > Pavel Fedin (4): > Add virt-v3 machine that uses GIC-500 > Set kernel_irqchip_type for other ARM boards which use GIC > First bits of vGICv3 support: > Initial implementation of vGICv3. > > hw/arm/exynos4_boards.c | 1 + > hw/arm/realview.c | 1 + > hw/arm/vexpress.c | 1 + > hw/arm/virt.c | 148 - > hw/intc/Makefile.objs | 1 + > hw/intc/arm_gicv3_kvm.c | 283 > > include/hw/boards.h | 1 + > include/sysemu/kvm.h| 3 +- > kvm-all.c | 2 +- > stubs/kvm.c | 2 +- > target-arm/kvm.c| 8 +- > 11 files changed, 419 insertions(+), 32 deletions(-) > create mode 100644 hw/intc/arm_gicv3_kvm.c > > -- > 1.9.5.msysgit.0 > >
[Qemu-devel] [PATCH RFC 0/4] vGICv3 support
This is my alternative to Ashok's vGICv3 patch (https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg03021.html), which i am currently working on. It addresses vGIC capability verification issue (kvm_irqchip_create() / kvm_arch_irqchip_create()), as well as offers better code structure (v3 code separated from v2). This patchset applies on top of this: https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00943.html. Note that GIC type selection still relies on machine name (virt-v3 vs virt), and not on machine option. Since libvirt has recently introduced support for extra options, i have absolutely nothing against Ashok's approach. I just did not change this yet because it would affect my testing environment. The aim of this RFC is to focus on vGICv3 implementation and related changes. And yes, i agree that v2 and v3 now have some copypasted code, and this is TBD. Pavel Fedin (4): Add virt-v3 machine that uses GIC-500 Set kernel_irqchip_type for other ARM boards which use GIC First bits of vGICv3 support: Initial implementation of vGICv3. hw/arm/exynos4_boards.c | 1 + hw/arm/realview.c | 1 + hw/arm/vexpress.c | 1 + hw/arm/virt.c | 148 - hw/intc/Makefile.objs | 1 + hw/intc/arm_gicv3_kvm.c | 283 include/hw/boards.h | 1 + include/sysemu/kvm.h| 3 +- kvm-all.c | 2 +- stubs/kvm.c | 2 +- target-arm/kvm.c| 8 +- 11 files changed, 419 insertions(+), 32 deletions(-) create mode 100644 hw/intc/arm_gicv3_kvm.c -- 1.9.5.msysgit.0
