[PATCH v5 00/19] KVM GICv3 emulation

[andre.przywara@arm.com (Andre Przywara)]

Hej Christoffer,

On 13/12/14 13:53, Christoffer Dall wrote:
> Hi Andre,
> 
> On Mon, Dec 08, 2014 at 12:37:35PM +0000, Andre Przywara wrote:
>> This is version 5 of the GICv3 guest emulation series (not for 3.19).
>>
>> As the changes this time were much smaller, I updated to tree to
>> 3.18.0, as it includes some bug fixes in the VGIC.
>>
>> I addressed the remaining comments from Christoffer and Eric, thanks
>> for the review! The changes this times were much smaller, most of them
>> cosmetic or rewordings of commit messages and comments.
>> I updated the kvm-gicv3/v4 branch in my repo[1] to carry all the delta
>> patches. Those patches are just for reference to see what has changed
>> between v4 and v5. For review and all other purposes please use the
>> v5 branch.
>>
>> For a changelog summary see below, also each patch carries a changelog
>> now.
>> Only patches 05, 08, 12, 15, 17, 18 and 19 have been changed compared
>> to v4. I dropped Christoffer's Reviewed-by: tag from 05/19 because of
>> the newly added function, but added the respective tags to the other
>> commit messages.
>>
>> I quickly tested this version with a GICv3 capable fast model in all
>> endianness modes (LE guest on LE host, BE on LE, LE on BE, BE on BE).
>> Both a GICv2 and a GICv3 guest were booted in all four combinations.
>>
> So this is overall looking like it's getting ready to be merged for
> v3.20.
> 
> However, here are the things we need resolved before putting it into
> kvmarm/next:
> 
> 1. You need to address the few remaining comments I had on this version.
> 
> 2. You must rebase on the vgic_init series and the vcpu_nit series.
>    Both are in kvmarm/queue, so I suggest you rebase on that or wait
>    until both of those series hit kvm/next (later next week).  You also
>    need to base this on Eric's VGIC init ioctl series
>    (https://lists.cs.columbia.edu/pipermail/kvmarm/2014-December/012643.html),
>    but with dropping patch 3.  As soon as Marc has taken a look at that
>    series, I will merge it onto queue as well.
>    This is likely going to be a pain (sorry about that) since the whole
>    init/init_maps sequence has changed.
> 
> 3. Get rid of any on-demand calls to vgic_init() for GICv3.  For GICv3,
>    the only valid call to vgic_init() should be from the new device
>    control ioctl, and all other paths that rely on vgic_init() must
>    fail.
> 
> 4. Resubmit a new (and hopefully final) version of the series soon after
>    the merge window closes.
> 
> Then we'll queue this in kvmarm/next early so that we have time to test
> it and expose it to a wider audience.

Alright, thanks for that, sounds like a plan. I will try my best to do
the rebasing this week still, so that the new series arrives as early as
possible after -rc1.

Cheers,
Andre.