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 boa
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
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
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 add
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_ar
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 cod