linux-next: manual merge of the kvm-arm tree with Linus' tree

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit ae705930fca6 ("arm/arm64: KVM: Keep
elrsr/aisr in sync with software model") from Linus' tree and commit
71760950bf3d ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn")
from the kvm-arm tree.

I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc virt/kvm/arm/vgic.c
index c9f60f524588,ffd937ca5141..000000000000
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
  		if (vlr.source == sgi_source_id) {
  			kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
  			BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
- 			vlr.state |= LR_STATE_PENDING;
- 			vgic_set_lr(vcpu, lr, vlr);
+ 			vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
 +			vgic_sync_lr_elrsr(vcpu, lr, vlr);
  			return true;
  		}
  	}
@@@ -1001,12 -1109,8 +1116,9 @@@
  
  	vlr.irq = irq;
  	vlr.source = sgi_source_id;
- 	vlr.state = LR_STATE_PENDING;
- 	if (!vgic_irq_is_edge(vcpu, irq))
- 		vlr.state |= LR_EOI_INT;
- 
- 	vgic_set_lr(vcpu, lr, vlr);
+ 	vlr.state = 0;
+ 	vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
 +	vgic_sync_lr_elrsr(vcpu, lr, vlr);
  
  	return true;
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Christoffer Dall]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

Hi Stephen,

On Wed, Mar 18, 2015 at 02:41:11PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm-arm tree got a conflict in
> virt/kvm/arm/vgic.c between commit ae705930fca6 ("arm/arm64: KVM: Keep
> elrsr/aisr in sync with software model") from Linus' tree and commit
> 71760950bf3d ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn")
> from the kvm-arm tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc virt/kvm/arm/vgic.c
> index c9f60f524588,ffd937ca5141..000000000000
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
>   		if (vlr.source == sgi_source_id) {
>   			kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
>   			BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> - 			vlr.state |= LR_STATE_PENDING;
> - 			vgic_set_lr(vcpu, lr, vlr);
> + 			vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>  +			vgic_sync_lr_elrsr(vcpu, lr, vlr);
>   			return true;
>   		}
>   	}
> @@@ -1001,12 -1109,8 +1116,9 @@@
>   
>   	vlr.irq = irq;
>   	vlr.source = sgi_source_id;
> - 	vlr.state = LR_STATE_PENDING;
> - 	if (!vgic_irq_is_edge(vcpu, irq))
> - 		vlr.state |= LR_EOI_INT;
> - 
> - 	vgic_set_lr(vcpu, lr, vlr);
> + 	vlr.state = 0;
> + 	vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>  +	vgic_sync_lr_elrsr(vcpu, lr, vlr);
>   
>   	return true;
>   }


Looks great, thanks!
-Christoffer

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Paolo Bonzini]

On 18/03/2015 08:55, Christoffer Dall wrote:
> Hi Stephen,
> 
> On Wed, Mar 18, 2015 at 02:41:11PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the kvm-arm tree got a conflict in
>> virt/kvm/arm/vgic.c between commit ae705930fca6 ("arm/arm64: KVM: Keep
>> elrsr/aisr in sync with software model") from Linus' tree and commit
>> 71760950bf3d ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn")
>> from the kvm-arm tree.
>>
>> I fixed it up (I think - see below) and can carry the fix as necessary
>> (no action is required).
>>
>> -- 
>> Cheers,
>> Stephen Rothwell                    sfr@canb.auug.org.au
>>
>> diff --cc virt/kvm/arm/vgic.c
>> index c9f60f524588,ffd937ca5141..000000000000
>> --- a/virt/kvm/arm/vgic.c
>> +++ b/virt/kvm/arm/vgic.c
>> @@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
>>   		if (vlr.source == sgi_source_id) {
>>   			kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
>>   			BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
>> - 			vlr.state |= LR_STATE_PENDING;
>> - 			vgic_set_lr(vcpu, lr, vlr);
>> + 			vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>>  +			vgic_sync_lr_elrsr(vcpu, lr, vlr);
>>   			return true;
>>   		}
>>   	}
>> @@@ -1001,12 -1109,8 +1116,9 @@@
>>   
>>   	vlr.irq = irq;
>>   	vlr.source = sgi_source_id;
>> - 	vlr.state = LR_STATE_PENDING;
>> - 	if (!vgic_irq_is_edge(vcpu, irq))
>> - 		vlr.state |= LR_EOI_INT;
>> - 
>> - 	vgic_set_lr(vcpu, lr, vlr);
>> + 	vlr.state = 0;
>> + 	vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>>  +	vgic_sync_lr_elrsr(vcpu, lr, vlr);
>>   
>>   	return true;
>>   }
> 
> Looks great, thanks!
> -Christoffer

Got the same conflict when pulling from the kvm-arm tree, I used
a different resolution though:

diff --cc virt/kvm/arm/vgic.c
index c9f60f524588,b70174e74868..8d550ff14700
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -955,6 -1095,25 +1101,26 @@@ static void vgic_retire_disabled_irqs(s
  	}
  }
  
+ static void vgic_queue_irq_to_lr(struct kvm_vcpu *vcpu, int irq,
+ 				 int lr_nr, struct vgic_lr vlr)
+ {
+ 	if (vgic_irq_is_active(vcpu, irq)) {
+ 		vlr.state |= LR_STATE_ACTIVE;
+ 		kvm_debug("Set active, clear distributor: 0x%x\n", vlr.state);
+ 		vgic_irq_clear_active(vcpu, irq);
+ 		vgic_update_state(vcpu->kvm);
+ 	} else if (vgic_dist_irq_is_pending(vcpu, irq)) {
+ 		vlr.state |= LR_STATE_PENDING;
+ 		kvm_debug("Set pending: 0x%x\n", vlr.state);
+ 	}
+ 
+ 	if (!vgic_irq_is_edge(vcpu, irq))
+ 		vlr.state |= LR_EOI_INT;
+ 
+ 	vgic_set_lr(vcpu, lr_nr, vlr);
++	vgic_sync_lr_elrsr(vcpu, lr_nr, vlr);
+ }
+ 
  /*
   * Queue an interrupt to a CPU virtual interface. Return true on success,
   * or false if it wasn't possible to queue it.
@@@ -982,9 -1141,7 +1148,7 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
                if (vlr.source == sgi_source_id) {
                        kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
                        BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
-                       vlr.state |= LR_STATE_PENDING;
-                       vgic_set_lr(vcpu, lr, vlr);
-                       vgic_sync_lr_elrsr(vcpu, lr, vlr);
+                       vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
                        return true;
                }
        }
@@@ -1001,12 -1158,8 +1165,8 @@@
  
        vlr.irq = irq;
        vlr.source = sgi_source_id;
-       vlr.state = LR_STATE_PENDING;
-       if (!vgic_irq_is_edge(vcpu, irq))
-               vlr.state |= LR_EOI_INT;
- 
-       vgic_set_lr(vcpu, lr, vlr);
-       vgic_sync_lr_elrsr(vcpu, lr, vlr);
+       vlr.state = 0;
+       vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
  
        return true;
  }


Christoffer, this is the same logic as Stephen's resolution, but
can you confirm that it makes sense "semantically" as well?

(Stephen, you'll still get the conflicts in linux-next for a
couple of days as I finish local testing of KVM changes for 4.1).

Paolo

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Marc Zyngier]

On Tue, 7 Apr 2015 17:20:15 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

Hi Paolo,

> On 18/03/2015 08:55, Christoffer Dall wrote:
> > Hi Stephen,
> > 
> > On Wed, Mar 18, 2015 at 02:41:11PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Today's linux-next merge of the kvm-arm tree got a conflict in
> >> virt/kvm/arm/vgic.c between commit ae705930fca6 ("arm/arm64: KVM: Keep
> >> elrsr/aisr in sync with software model") from Linus' tree and commit
> >> 71760950bf3d ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn")
> >> from the kvm-arm tree.
> >>
> >> I fixed it up (I think - see below) and can carry the fix as necessary
> >> (no action is required).
> >>
> >> -- 
> >> Cheers,
> >> Stephen Rothwell                    sfr@canb.auug.org.au
> >>
> >> diff --cc virt/kvm/arm/vgic.c
> >> index c9f60f524588,ffd937ca5141..000000000000
> >> --- a/virt/kvm/arm/vgic.c
> >> +++ b/virt/kvm/arm/vgic.c
> >> @@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
> >>   		if (vlr.source == sgi_source_id) {
> >>   			kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
> >>   			BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> >> - 			vlr.state |= LR_STATE_PENDING;
> >> - 			vgic_set_lr(vcpu, lr, vlr);
> >> + 			vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> >>  +			vgic_sync_lr_elrsr(vcpu, lr, vlr);
> >>   			return true;
> >>   		}
> >>   	}
> >> @@@ -1001,12 -1109,8 +1116,9 @@@
> >>   
> >>   	vlr.irq = irq;
> >>   	vlr.source = sgi_source_id;
> >> - 	vlr.state = LR_STATE_PENDING;
> >> - 	if (!vgic_irq_is_edge(vcpu, irq))
> >> - 		vlr.state |= LR_EOI_INT;
> >> - 
> >> - 	vgic_set_lr(vcpu, lr, vlr);
> >> + 	vlr.state = 0;
> >> + 	vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> >>  +	vgic_sync_lr_elrsr(vcpu, lr, vlr);
> >>   
> >>   	return true;
> >>   }
> > 
> > Looks great, thanks!
> > -Christoffer
> 
> Got the same conflict when pulling from the kvm-arm tree, I used
> a different resolution though:
> 
> diff --cc virt/kvm/arm/vgic.c
> index c9f60f524588,b70174e74868..8d550ff14700
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@@ -955,6 -1095,25 +1101,26 @@@ static void vgic_retire_disabled_irqs(s
>   	}
>   }
>   
> + static void vgic_queue_irq_to_lr(struct kvm_vcpu *vcpu, int irq,
> + 				 int lr_nr, struct vgic_lr vlr)
> + {
> + 	if (vgic_irq_is_active(vcpu, irq)) {
> + 		vlr.state |= LR_STATE_ACTIVE;
> + 		kvm_debug("Set active, clear distributor: 0x%x\n", vlr.state);
> + 		vgic_irq_clear_active(vcpu, irq);
> + 		vgic_update_state(vcpu->kvm);
> + 	} else if (vgic_dist_irq_is_pending(vcpu, irq)) {
> + 		vlr.state |= LR_STATE_PENDING;
> + 		kvm_debug("Set pending: 0x%x\n", vlr.state);
> + 	}
> + 
> + 	if (!vgic_irq_is_edge(vcpu, irq))
> + 		vlr.state |= LR_EOI_INT;
> + 
> + 	vgic_set_lr(vcpu, lr_nr, vlr);
> ++	vgic_sync_lr_elrsr(vcpu, lr_nr, vlr);
> + }
> + 
>   /*
>    * Queue an interrupt to a CPU virtual interface. Return true on success,
>    * or false if it wasn't possible to queue it.
> @@@ -982,9 -1141,7 +1148,7 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
>                 if (vlr.source == sgi_source_id) {
>                         kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
>                         BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> -                       vlr.state |= LR_STATE_PENDING;
> -                       vgic_set_lr(vcpu, lr, vlr);
> -                       vgic_sync_lr_elrsr(vcpu, lr, vlr);
> +                       vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>                         return true;
>                 }
>         }
> @@@ -1001,12 -1158,8 +1165,8 @@@
>   
>         vlr.irq = irq;
>         vlr.source = sgi_source_id;
> -       vlr.state = LR_STATE_PENDING;
> -       if (!vgic_irq_is_edge(vcpu, irq))
> -               vlr.state |= LR_EOI_INT;
> - 
> -       vgic_set_lr(vcpu, lr, vlr);
> -       vgic_sync_lr_elrsr(vcpu, lr, vlr);
> +       vlr.state = 0;
> +       vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>   
>         return true;
>   }
> 
> 
> Christoffer, this is the same logic as Stephen's resolution, but
> can you confirm that it makes sense "semantically" as well?

This looks like a sensible resolution to me. I've given it a spin, and
it seems to behave as expected.

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Christoffer Dall]

On Wed, Apr 08, 2015 at 09:15:13AM +0100, Marc Zyngier wrote:
> On Tue, 7 Apr 2015 17:20:15 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> Hi Paolo,
> 
> > On 18/03/2015 08:55, Christoffer Dall wrote:
> > > Hi Stephen,
> > > 
> > > On Wed, Mar 18, 2015 at 02:41:11PM +1100, Stephen Rothwell wrote:
> > >> Hi all,
> > >>
> > >> Today's linux-next merge of the kvm-arm tree got a conflict in
> > >> virt/kvm/arm/vgic.c between commit ae705930fca6 ("arm/arm64: KVM: Keep
> > >> elrsr/aisr in sync with software model") from Linus' tree and commit
> > >> 71760950bf3d ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn")
> > >> from the kvm-arm tree.
> > >>
> > >> I fixed it up (I think - see below) and can carry the fix as necessary
> > >> (no action is required).
> > >>
> > >> -- 
> > >> Cheers,
> > >> Stephen Rothwell                    sfr@canb.auug.org.au
> > >>
> > >> diff --cc virt/kvm/arm/vgic.c
> > >> index c9f60f524588,ffd937ca5141..000000000000
> > >> --- a/virt/kvm/arm/vgic.c
> > >> +++ b/virt/kvm/arm/vgic.c
> > >> @@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
> > >>   		if (vlr.source == sgi_source_id) {
> > >>   			kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
> > >>   			BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> > >> - 			vlr.state |= LR_STATE_PENDING;
> > >> - 			vgic_set_lr(vcpu, lr, vlr);
> > >> + 			vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> > >>  +			vgic_sync_lr_elrsr(vcpu, lr, vlr);
> > >>   			return true;
> > >>   		}
> > >>   	}
> > >> @@@ -1001,12 -1109,8 +1116,9 @@@
> > >>   
> > >>   	vlr.irq = irq;
> > >>   	vlr.source = sgi_source_id;
> > >> - 	vlr.state = LR_STATE_PENDING;
> > >> - 	if (!vgic_irq_is_edge(vcpu, irq))
> > >> - 		vlr.state |= LR_EOI_INT;
> > >> - 
> > >> - 	vgic_set_lr(vcpu, lr, vlr);
> > >> + 	vlr.state = 0;
> > >> + 	vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> > >>  +	vgic_sync_lr_elrsr(vcpu, lr, vlr);
> > >>   
> > >>   	return true;
> > >>   }
> > > 
> > > Looks great, thanks!
> > > -Christoffer
> > 
> > Got the same conflict when pulling from the kvm-arm tree, I used
> > a different resolution though:
> > 
> > diff --cc virt/kvm/arm/vgic.c
> > index c9f60f524588,b70174e74868..8d550ff14700
> > --- a/virt/kvm/arm/vgic.c
> > +++ b/virt/kvm/arm/vgic.c
> > @@@ -955,6 -1095,25 +1101,26 @@@ static void vgic_retire_disabled_irqs(s
> >   	}
> >   }
> >   
> > + static void vgic_queue_irq_to_lr(struct kvm_vcpu *vcpu, int irq,
> > + 				 int lr_nr, struct vgic_lr vlr)
> > + {
> > + 	if (vgic_irq_is_active(vcpu, irq)) {
> > + 		vlr.state |= LR_STATE_ACTIVE;
> > + 		kvm_debug("Set active, clear distributor: 0x%x\n", vlr.state);
> > + 		vgic_irq_clear_active(vcpu, irq);
> > + 		vgic_update_state(vcpu->kvm);
> > + 	} else if (vgic_dist_irq_is_pending(vcpu, irq)) {
> > + 		vlr.state |= LR_STATE_PENDING;
> > + 		kvm_debug("Set pending: 0x%x\n", vlr.state);
> > + 	}
> > + 
> > + 	if (!vgic_irq_is_edge(vcpu, irq))
> > + 		vlr.state |= LR_EOI_INT;
> > + 
> > + 	vgic_set_lr(vcpu, lr_nr, vlr);
> > ++	vgic_sync_lr_elrsr(vcpu, lr_nr, vlr);
> > + }
> > + 
> >   /*
> >    * Queue an interrupt to a CPU virtual interface. Return true on success,
> >    * or false if it wasn't possible to queue it.
> > @@@ -982,9 -1141,7 +1148,7 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
> >                 if (vlr.source == sgi_source_id) {
> >                         kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
> >                         BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> > -                       vlr.state |= LR_STATE_PENDING;
> > -                       vgic_set_lr(vcpu, lr, vlr);
> > -                       vgic_sync_lr_elrsr(vcpu, lr, vlr);
> > +                       vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> >                         return true;
> >                 }
> >         }
> > @@@ -1001,12 -1158,8 +1165,8 @@@
> >   
> >         vlr.irq = irq;
> >         vlr.source = sgi_source_id;
> > -       vlr.state = LR_STATE_PENDING;
> > -       if (!vgic_irq_is_edge(vcpu, irq))
> > -               vlr.state |= LR_EOI_INT;
> > - 
> > -       vgic_set_lr(vcpu, lr, vlr);
> > -       vgic_sync_lr_elrsr(vcpu, lr, vlr);
> > +       vlr.state = 0;
> > +       vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> >   
> >         return true;
> >   }
> > 
> > 
> > Christoffer, this is the same logic as Stephen's resolution, but
> > can you confirm that it makes sense "semantically" as well?
> 
> This looks like a sensible resolution to me. I've given it a spin, and
> it seems to behave as expected.
> 
Yes, this is semantically slightly nicer in fact.

Thanks,
-Christoffer

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Christoffer Dall]

Hi Paolo and Marc,

On Tue, Apr 07, 2015 at 06:20:15PM +0200, Paolo Bonzini wrote:
> 
> 
> On 18/03/2015 08:55, Christoffer Dall wrote:
> > Hi Stephen,
> > 
> > On Wed, Mar 18, 2015 at 02:41:11PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Today's linux-next merge of the kvm-arm tree got a conflict in
> >> virt/kvm/arm/vgic.c between commit ae705930fca6 ("arm/arm64: KVM: Keep
> >> elrsr/aisr in sync with software model") from Linus' tree and commit
> >> 71760950bf3d ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn")
> >> from the kvm-arm tree.
> >>
> >> I fixed it up (I think - see below) and can carry the fix as necessary
> >> (no action is required).
> >>
> >> -- 
> >> Cheers,
> >> Stephen Rothwell                    sfr@canb.auug.org.au
> >>
> >> diff --cc virt/kvm/arm/vgic.c
> >> index c9f60f524588,ffd937ca5141..000000000000
> >> --- a/virt/kvm/arm/vgic.c
> >> +++ b/virt/kvm/arm/vgic.c
> >> @@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
> >>   		if (vlr.source == sgi_source_id) {
> >>   			kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
> >>   			BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> >> - 			vlr.state |= LR_STATE_PENDING;
> >> - 			vgic_set_lr(vcpu, lr, vlr);
> >> + 			vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> >>  +			vgic_sync_lr_elrsr(vcpu, lr, vlr);
> >>   			return true;
> >>   		}
> >>   	}
> >> @@@ -1001,12 -1109,8 +1116,9 @@@
> >>   
> >>   	vlr.irq = irq;
> >>   	vlr.source = sgi_source_id;
> >> - 	vlr.state = LR_STATE_PENDING;
> >> - 	if (!vgic_irq_is_edge(vcpu, irq))
> >> - 		vlr.state |= LR_EOI_INT;
> >> - 
> >> - 	vgic_set_lr(vcpu, lr, vlr);
> >> + 	vlr.state = 0;
> >> + 	vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
> >>  +	vgic_sync_lr_elrsr(vcpu, lr, vlr);
> >>   
> >>   	return true;
> >>   }
> > 
> > Looks great, thanks!
> > -Christoffer
> 
> Got the same conflict when pulling from the kvm-arm tree, I used
> a different resolution though:
> 
> diff --cc virt/kvm/arm/vgic.c
> index c9f60f524588,b70174e74868..8d550ff14700
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@@ -955,6 -1095,25 +1101,26 @@@ static void vgic_retire_disabled_irqs(s
>   	}
>   }
>   
> + static void vgic_queue_irq_to_lr(struct kvm_vcpu *vcpu, int irq,
> + 				 int lr_nr, struct vgic_lr vlr)
> + {
> + 	if (vgic_irq_is_active(vcpu, irq)) {
> + 		vlr.state |= LR_STATE_ACTIVE;
> + 		kvm_debug("Set active, clear distributor: 0x%x\n", vlr.state);
> + 		vgic_irq_clear_active(vcpu, irq);
> + 		vgic_update_state(vcpu->kvm);
> + 	} else if (vgic_dist_irq_is_pending(vcpu, irq)) {
> + 		vlr.state |= LR_STATE_PENDING;
> + 		kvm_debug("Set pending: 0x%x\n", vlr.state);
> + 	}
> + 
> + 	if (!vgic_irq_is_edge(vcpu, irq))
> + 		vlr.state |= LR_EOI_INT;
> + 
> + 	vgic_set_lr(vcpu, lr_nr, vlr);
> ++	vgic_sync_lr_elrsr(vcpu, lr_nr, vlr);
> + }
> + 
>   /*
>    * Queue an interrupt to a CPU virtual interface. Return true on success,
>    * or false if it wasn't possible to queue it.
> @@@ -982,9 -1141,7 +1148,7 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
>                 if (vlr.source == sgi_source_id) {
>                         kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
>                         BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
> -                       vlr.state |= LR_STATE_PENDING;
> -                       vgic_set_lr(vcpu, lr, vlr);
> -                       vgic_sync_lr_elrsr(vcpu, lr, vlr);
> +                       vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>                         return true;
>                 }
>         }
> @@@ -1001,12 -1158,8 +1165,8 @@@
>   
>         vlr.irq = irq;
>         vlr.source = sgi_source_id;
> -       vlr.state = LR_STATE_PENDING;
> -       if (!vgic_irq_is_edge(vcpu, irq))
> -               vlr.state |= LR_EOI_INT;
> - 
> -       vgic_set_lr(vcpu, lr, vlr);
> -       vgic_sync_lr_elrsr(vcpu, lr, vlr);
> +       vlr.state = 0;
> +       vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
>   
>         return true;
>   }
> 
> 
> Christoffer, this is the same logic as Stephen's resolution, but
> can you confirm that it makes sense "semantically" as well?
> 
> (Stephen, you'll still get the conflicts in linux-next for a
> couple of days as I finish local testing of KVM changes for 4.1).
> 
As it turns out, it was not the same logic as Stephen's resolution.
Stephen's resolution is bussy, because vlr is passed by value to
vgic_queue_irq_to_lr() and therefore the call to sync the elrsr does not
have any effect.

Unfortunately, it seems Paolo's more correct fix did not end up in
Linus' tree, so I guess I should just send a patch?

-Christoffer

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Paolo Bonzini]

On 16/04/2015 21:10, Christoffer Dall wrote:
>> > 
> As it turns out, it was not the same logic as Stephen's resolution.
> Stephen's resolution is bussy, because vlr is passed by value to
> vgic_queue_irq_to_lr() and therefore the call to sync the elrsr does not
> have any effect.
> 
> Unfortunately, it seems Paolo's more correct fix did not end up in
> Linus' tree, so I guess I should just send a patch?

Uhm, sure it did :)

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/virt/kvm/arm/vgic.c#n1121

Stephen's resolutions never end up in Linus's tree, as Stephen never
sends anything to Linus.

Paolo

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Christoffer Dall]

On Thu, Apr 16, 2015 at 09:39:06PM +0200, Paolo Bonzini wrote:
> 
> 
> On 16/04/2015 21:10, Christoffer Dall wrote:
> >> > 
> > As it turns out, it was not the same logic as Stephen's resolution.
> > Stephen's resolution is bussy, because vlr is passed by value to
> > vgic_queue_irq_to_lr() and therefore the call to sync the elrsr does not
> > have any effect.
> > 
> > Unfortunately, it seems Paolo's more correct fix did not end up in
> > Linus' tree, so I guess I should just send a patch?
> 
> Uhm, sure it did :)
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/virt/kvm/arm/vgic.c#n1121
> 

I'm an idiot; I looked at 4.0 instead of master, sorry for the noise.

-Christoffer

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  virt/kvm/arm/arch_timer.c

between commit:

  36e5cfd410ad ("KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state")

from Linus' tree and commit:

  70450a9fbe06 ("KVM: arm/arm64: Don't cache the timer IRQ level")

from the kvm-arm tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc virt/kvm/arm/arch_timer.c
index cc29a8148328,cfcd0323deab..000000000000
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@@ -92,27 -92,19 +92,26 @@@ static irqreturn_t kvm_arch_timer_handl
  {
  	struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
  	struct arch_timer_context *vtimer;
 +	u32 cnt_ctl;
  
 -	if (!vcpu) {
 -		pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
 -		return IRQ_NONE;
 -	}
 -	vtimer = vcpu_vtimer(vcpu);
 +	/*
 +	 * We may see a timer interrupt after vcpu_put() has been called which
 +	 * sets the CPU's vcpu pointer to NULL, because even though the timer
 +	 * has been disabled in vtimer_save_state(), the hardware interrupt
 +	 * signal may not have been retired from the interrupt controller yet.
 +	 */
 +	if (!vcpu)
 +		return IRQ_HANDLED;
  
 -	vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
 -	if (kvm_timer_irq_can_fire(vtimer))
 +	vtimer = vcpu_vtimer(vcpu);
- 	if (!vtimer->irq.level) {
- 		cnt_ctl = read_sysreg_el0(cntv_ctl);
- 		cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
- 			   ARCH_TIMER_CTRL_IT_MASK;
- 		if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
- 			kvm_timer_update_irq(vcpu, true, vtimer);
- 	}
- 
- 	if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
++	cnt_ctl = read_sysreg_el0(cntv_ctl);
++	cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
++		   ARCH_TIMER_CTRL_IT_MASK;
++	if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
+ 		kvm_timer_update_irq(vcpu, true, vtimer);
+ 
+ 	if (static_branch_unlikely(&userspace_irqchip_in_use) &&
+ 	    unlikely(!irqchip_in_kernel(vcpu->kvm)))
  		kvm_vtimer_update_mask_user(vcpu);
  
  	return IRQ_HANDLED;

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Christoffer Dall]

Thanks Stephen,

On Wed, Jan 3, 2018 at 3:38 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the kvm-arm tree got a conflict in:
>
>   virt/kvm/arm/arch_timer.c
>
> between commit:
>
>   36e5cfd410ad ("KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state")
>
> from Linus' tree and commit:
>
>   70450a9fbe06 ("KVM: arm/arm64: Don't cache the timer IRQ level")
>
> from the kvm-arm tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary.
> This is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The resolution looks correct to me.

cc'ing the KVM maintainers in case they want to merge kvm/master into
kvm/next to avoid the conflict going up to Linus.

Thanks,
-Christoffer

>
> diff --cc virt/kvm/arm/arch_timer.c
> index cc29a8148328,cfcd0323deab..000000000000
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@@ -92,27 -92,19 +92,26 @@@ static irqreturn_t kvm_arch_timer_handl
>   {
>         struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
>         struct arch_timer_context *vtimer;
>  +      u32 cnt_ctl;
>
>  -      if (!vcpu) {
>  -              pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
>  -              return IRQ_NONE;
>  -      }
>  -      vtimer = vcpu_vtimer(vcpu);
>  +      /*
>  +       * We may see a timer interrupt after vcpu_put() has been called which
>  +       * sets the CPU's vcpu pointer to NULL, because even though the timer
>  +       * has been disabled in vtimer_save_state(), the hardware interrupt
>  +       * signal may not have been retired from the interrupt controller yet.
>  +       */
>  +      if (!vcpu)
>  +              return IRQ_HANDLED;
>
>  -      vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>  -      if (kvm_timer_irq_can_fire(vtimer))
>  +      vtimer = vcpu_vtimer(vcpu);
> -       if (!vtimer->irq.level) {
> -               cnt_ctl = read_sysreg_el0(cntv_ctl);
> -               cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
> -                          ARCH_TIMER_CTRL_IT_MASK;
> -               if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
> -                       kvm_timer_update_irq(vcpu, true, vtimer);
> -       }
> -
> -       if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
> ++      cnt_ctl = read_sysreg_el0(cntv_ctl);
> ++      cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT |
> ++                 ARCH_TIMER_CTRL_IT_MASK;
> ++      if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT))
> +               kvm_timer_update_irq(vcpu, true, vtimer);
> +
> +       if (static_branch_unlikely(&userspace_irqchip_in_use) &&
> +           unlikely(!irqchip_in_kernel(vcpu->kvm)))
>                 kvm_vtimer_update_mask_user(vcpu);
>
>         return IRQ_HANDLED;

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kvm/inject_fault.c

between commit:

  fd6c8c206fc5 ("arm/arm64: KVM: set right LR register value for 32 bit guest when inject abort")

from Linus' tree and commit:

  00586cdaf597 ("KVM: arm/arm64: Unify 32bit fault injection")

from the kvm-arm tree.

I fixed it up (I just used the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm/kvm/emulate.c

between commit:

  fd6c8c206fc5 ("arm/arm64: KVM: set right LR register value for 32 bit guest when inject abort")

from Linus' tree and commit:

  00586cdaf597 ("KVM: arm/arm64: Unify 32bit fault injection")

from the kvm-arm tree.

I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got conflicts in:

  virt/kvm/arm/vgic/vgic-v2.c
  virt/kvm/arm/vgic/vgic.h

between commit:

  5b0d2cc28058 ("KVM: arm64: Ensure LRs are clear when they should be")

from Linus' tree and commits:

  328e56647944 ("KVM: arm/arm64: vgic: Defer touching GICH_VMCR to vcpu_load/put")
  af0614991ab6 ("KVM: arm/arm64: vgic: Get rid of unnecessary process_maintenance operation")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc virt/kvm/arm/vgic/vgic-v2.c
index b637d9c7afe3,025b57d5787e..000000000000
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@@ -22,36 -22,7 +22,22 @@@
  
  #include "vgic.h"
  
- /*
-  * Call this function to convert a u64 value to an unsigned long * bitmask
-  * in a way that works on both 32-bit and 64-bit LE and BE platforms.
-  *
-  * Warning: Calling this function may modify *val.
-  */
- static unsigned long *u64_to_bitmask(u64 *val)
- {
- #if defined(CONFIG_CPU_BIG_ENDIAN) && BITS_PER_LONG == 32
- 	*val = (*val >> 32) | (*val << 32);
- #endif
- 	return (unsigned long *)val;
- }
- 
 +static inline void vgic_v2_write_lr(int lr, u32 val)
 +{
 +	void __iomem *base = kvm_vgic_global_state.vctrl_base;
 +
 +	writel_relaxed(val, base + GICH_LR0 + (lr * 4));
 +}
 +
 +void vgic_v2_init_lrs(void)
 +{
 +	int i;
 +
 +	for (i = 0; i < kvm_vgic_global_state.nr_lr; i++)
 +		vgic_v2_write_lr(i, 0);
 +}
 +
- void vgic_v2_process_maintenance(struct kvm_vcpu *vcpu)
+ void vgic_v2_set_underflow(struct kvm_vcpu *vcpu)
  {
  	struct vgic_v2_cpu_if *cpuif = &vcpu->arch.vgic_cpu.vgic_v2;
  
@@@ -206,10 -160,10 +175,10 @@@ void vgic_v2_set_vmcr(struct kvm_vcpu *
  		GICH_VMCR_ALIAS_BINPOINT_MASK;
  	vmcr |= (vmcrp->bpr << GICH_VMCR_BINPOINT_SHIFT) &
  		GICH_VMCR_BINPOINT_MASK;
 -	vmcr |= (vmcrp->pmr << GICH_VMCR_PRIMASK_SHIFT) &
 -		GICH_VMCR_PRIMASK_MASK;
 +	vmcr |= ((vmcrp->pmr >> GICV_PMR_PRIORITY_SHIFT) <<
 +		 GICH_VMCR_PRIMASK_SHIFT) & GICH_VMCR_PRIMASK_MASK;
  
- 	vcpu->arch.vgic_cpu.vgic_v2.vgic_vmcr = vmcr;
+ 	cpu_if->vgic_vmcr = vmcr;
  }
  
  void vgic_v2_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcrp)
diff --cc virt/kvm/arm/vgic/vgic.h
index 6cf557e9f718,44445dac0835..000000000000
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@@ -137,7 -129,8 +136,9 @@@ int vgic_v2_map_resources(struct kvm *k
  int vgic_register_dist_iodev(struct kvm *kvm, gpa_t dist_base_address,
  			     enum vgic_type);
  
 +void vgic_v2_init_lrs(void);
+ void vgic_v2_load(struct kvm_vcpu *vcpu);
+ void vgic_v2_put(struct kvm_vcpu *vcpu);
  
  static inline void vgic_get_irq_kref(struct vgic_irq *irq)
  {

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Christoffer Dall]

Hi Stephen,

On Mon, Apr 10, 2017 at 02:02:08PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the kvm-arm tree got conflicts in:
> 
>   virt/kvm/arm/vgic/vgic-v2.c
>   virt/kvm/arm/vgic/vgic.h
> 
> between commit:
> 
>   5b0d2cc28058 ("KVM: arm64: Ensure LRs are clear when they should be")
> 
> from Linus' tree and commits:
> 
>   328e56647944 ("KVM: arm/arm64: vgic: Defer touching GICH_VMCR to vcpu_load/put")
>   af0614991ab6 ("KVM: arm/arm64: vgic: Get rid of unnecessary process_maintenance operation")
> 
> from the kvm-arm tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Looks good, thanks.
-Christoffer

> 
> diff --cc virt/kvm/arm/vgic/vgic-v2.c
> index b637d9c7afe3,025b57d5787e..000000000000
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@@ -22,36 -22,7 +22,22 @@@
>   
>   #include "vgic.h"
>   
> - /*
> -  * Call this function to convert a u64 value to an unsigned long * bitmask
> -  * in a way that works on both 32-bit and 64-bit LE and BE platforms.
> -  *
> -  * Warning: Calling this function may modify *val.
> -  */
> - static unsigned long *u64_to_bitmask(u64 *val)
> - {
> - #if defined(CONFIG_CPU_BIG_ENDIAN) && BITS_PER_LONG == 32
> - 	*val = (*val >> 32) | (*val << 32);
> - #endif
> - 	return (unsigned long *)val;
> - }
> - 
>  +static inline void vgic_v2_write_lr(int lr, u32 val)
>  +{
>  +	void __iomem *base = kvm_vgic_global_state.vctrl_base;
>  +
>  +	writel_relaxed(val, base + GICH_LR0 + (lr * 4));
>  +}
>  +
>  +void vgic_v2_init_lrs(void)
>  +{
>  +	int i;
>  +
>  +	for (i = 0; i < kvm_vgic_global_state.nr_lr; i++)
>  +		vgic_v2_write_lr(i, 0);
>  +}
>  +
> - void vgic_v2_process_maintenance(struct kvm_vcpu *vcpu)
> + void vgic_v2_set_underflow(struct kvm_vcpu *vcpu)
>   {
>   	struct vgic_v2_cpu_if *cpuif = &vcpu->arch.vgic_cpu.vgic_v2;
>   
> @@@ -206,10 -160,10 +175,10 @@@ void vgic_v2_set_vmcr(struct kvm_vcpu *
>   		GICH_VMCR_ALIAS_BINPOINT_MASK;
>   	vmcr |= (vmcrp->bpr << GICH_VMCR_BINPOINT_SHIFT) &
>   		GICH_VMCR_BINPOINT_MASK;
>  -	vmcr |= (vmcrp->pmr << GICH_VMCR_PRIMASK_SHIFT) &
>  -		GICH_VMCR_PRIMASK_MASK;
>  +	vmcr |= ((vmcrp->pmr >> GICV_PMR_PRIORITY_SHIFT) <<
>  +		 GICH_VMCR_PRIMASK_SHIFT) & GICH_VMCR_PRIMASK_MASK;
>   
> - 	vcpu->arch.vgic_cpu.vgic_v2.vgic_vmcr = vmcr;
> + 	cpu_if->vgic_vmcr = vmcr;
>   }
>   
>   void vgic_v2_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcrp)
> diff --cc virt/kvm/arm/vgic/vgic.h
> index 6cf557e9f718,44445dac0835..000000000000
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@@ -137,7 -129,8 +136,9 @@@ int vgic_v2_map_resources(struct kvm *k
>   int vgic_register_dist_iodev(struct kvm *kvm, gpa_t dist_base_address,
>   			     enum vgic_type);
>   
>  +void vgic_v2_init_lrs(void);
> + void vgic_v2_load(struct kvm_vcpu *vcpu);
> + void vgic_v2_put(struct kvm_vcpu *vcpu);
>   
>   static inline void vgic_get_irq_kref(struct vgic_irq *irq)
>   {

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic-v2.c between commit 1f2bb4acc125 ("arm/arm64: KVM:
Fix unaligned access bug on gicv2 access") from Linus' tree and commit
2df36a5dd679 ("arm/arm64: KVM: Fix BE accesses to GICv2 EISR and ELRSR
regs") from the kvm-arm tree.

I fixed it up (since I don't know any better, I just used the kvm-arm
tree version) and can carry the fix as necessary (no action is
required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit 63afbe7a0ac1 ("kvm: arm64: vgic: fix
hyp panic with 64k pages on juno platform") from Linus' tree and commit
8f186d522c69 ("KVM: ARM: vgic: split GICv2 backend from the main vgic
code") and others from the kvm-arm tree.

I fixed it up (the latter extensively rewrites the function, so I just
used that) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Marc Zyngier]

On Thu, Jul 31 2014 at  7:30:04 am BST, Stephen Rothwell <sfr@canb.auug.org.au> wrote:

Hi Stephen,

> Today's linux-next merge of the kvm-arm tree got a conflict in
> virt/kvm/arm/vgic.c between commit 63afbe7a0ac1 ("kvm: arm64: vgic: fix
> hyp panic with 64k pages on juno platform") from Linus' tree and commit
> 8f186d522c69 ("KVM: ARM: vgic: split GICv2 backend from the main vgic
> code") and others from the kvm-arm tree.
>
> I fixed it up (the latter extensively rewrites the function, so I just
> used that) and can carry the fix as necessary (no action is required).

Thanks for the heads up. Here's the resolution I came up with:

commit cdc5159381f46d6475882d7051224e74c6256f60
Merge: 3a1122d d329de0
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Thu Jul 31 10:39:43 2014 +0100

    Merge remote-tracking branch 'kvmarm/next' into tmpmerge
    
    Conflicts:
    	virt/kvm/arm/vgic.c

diff --cc virt/kvm/arm/vgic-v2.c
index 0000000,d6c9c14..01124ef
mode 000000,100644..100644
--- a/virt/kvm/arm/vgic-v2.c
+++ b/virt/kvm/arm/vgic-v2.c
@@@ -1,0 -1,249 +1,265 @@@
+ /*
+  * Copyright (C) 2012,2013 ARM Limited, All Rights Reserved.
+  * Author: Marc Zyngier <marc.zyngier@arm.com>
+  *
+  * This program is free software; you can redistribute it and/or modify
+  * it under the terms of the GNU General Public License version 2 as
+  * published by the Free Software Foundation.
+  *
+  * This program is distributed in the hope that it will be useful,
+  * but WITHOUT ANY WARRANTY; without even the implied warranty of
+  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  * GNU General Public License for more details.
+  *
+  * You should have received a copy of the GNU General Public License
+  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+  */
+ 
+ #include <linux/cpu.h>
+ #include <linux/kvm.h>
+ #include <linux/kvm_host.h>
+ #include <linux/interrupt.h>
+ #include <linux/io.h>
+ #include <linux/of.h>
+ #include <linux/of_address.h>
+ #include <linux/of_irq.h>
+ 
+ #include <linux/irqchip/arm-gic.h>
+ 
+ #include <asm/kvm_emulate.h>
+ #include <asm/kvm_arm.h>
+ #include <asm/kvm_mmu.h>
+ 
+ static struct vgic_lr vgic_v2_get_lr(const struct kvm_vcpu *vcpu, int lr)
+ {
+ 	struct vgic_lr lr_desc;
+ 	u32 val = vcpu->arch.vgic_cpu.vgic_v2.vgic_lr[lr];
+ 
+ 	lr_desc.irq	= val & GICH_LR_VIRTUALID;
+ 	if (lr_desc.irq <= 15)
+ 		lr_desc.source	= (val >> GICH_LR_PHYSID_CPUID_SHIFT) & 0x7;
+ 	else
+ 		lr_desc.source = 0;
+ 	lr_desc.state	= 0;
+ 
+ 	if (val & GICH_LR_PENDING_BIT)
+ 		lr_desc.state |= LR_STATE_PENDING;
+ 	if (val & GICH_LR_ACTIVE_BIT)
+ 		lr_desc.state |= LR_STATE_ACTIVE;
+ 	if (val & GICH_LR_EOI)
+ 		lr_desc.state |= LR_EOI_INT;
+ 
+ 	return lr_desc;
+ }
+ 
+ static void vgic_v2_set_lr(struct kvm_vcpu *vcpu, int lr,
+ 			   struct vgic_lr lr_desc)
+ {
+ 	u32 lr_val = (lr_desc.source << GICH_LR_PHYSID_CPUID_SHIFT) | lr_desc.irq;
+ 
+ 	if (lr_desc.state & LR_STATE_PENDING)
+ 		lr_val |= GICH_LR_PENDING_BIT;
+ 	if (lr_desc.state & LR_STATE_ACTIVE)
+ 		lr_val |= GICH_LR_ACTIVE_BIT;
+ 	if (lr_desc.state & LR_EOI_INT)
+ 		lr_val |= GICH_LR_EOI;
+ 
+ 	vcpu->arch.vgic_cpu.vgic_v2.vgic_lr[lr] = lr_val;
+ }
+ 
+ static void vgic_v2_sync_lr_elrsr(struct kvm_vcpu *vcpu, int lr,
+ 				  struct vgic_lr lr_desc)
+ {
+ 	if (!(lr_desc.state & LR_STATE_MASK))
+ 		set_bit(lr, (unsigned long *)vcpu->arch.vgic_cpu.vgic_v2.vgic_elrsr);
+ }
+ 
+ static u64 vgic_v2_get_elrsr(const struct kvm_vcpu *vcpu)
+ {
+ 	u64 val;
+ 
+ #if BITS_PER_LONG == 64
+ 	val  = vcpu->arch.vgic_cpu.vgic_v2.vgic_elrsr[1];
+ 	val <<= 32;
+ 	val |= vcpu->arch.vgic_cpu.vgic_v2.vgic_elrsr[0];
+ #else
+ 	val = *(u64 *)vcpu->arch.vgic_cpu.vgic_v2.vgic_elrsr;
+ #endif
+ 	return val;
+ }
+ 
+ static u64 vgic_v2_get_eisr(const struct kvm_vcpu *vcpu)
+ {
+ 	u64 val;
+ 
+ #if BITS_PER_LONG == 64
+ 	val  = vcpu->arch.vgic_cpu.vgic_v2.vgic_eisr[1];
+ 	val <<= 32;
+ 	val |= vcpu->arch.vgic_cpu.vgic_v2.vgic_eisr[0];
+ #else
+ 	val = *(u64 *)vcpu->arch.vgic_cpu.vgic_v2.vgic_eisr;
+ #endif
+ 	return val;
+ }
+ 
+ static u32 vgic_v2_get_interrupt_status(const struct kvm_vcpu *vcpu)
+ {
+ 	u32 misr = vcpu->arch.vgic_cpu.vgic_v2.vgic_misr;
+ 	u32 ret = 0;
+ 
+ 	if (misr & GICH_MISR_EOI)
+ 		ret |= INT_STATUS_EOI;
+ 	if (misr & GICH_MISR_U)
+ 		ret |= INT_STATUS_UNDERFLOW;
+ 
+ 	return ret;
+ }
+ 
+ static void vgic_v2_enable_underflow(struct kvm_vcpu *vcpu)
+ {
+ 	vcpu->arch.vgic_cpu.vgic_v2.vgic_hcr |= GICH_HCR_UIE;
+ }
+ 
+ static void vgic_v2_disable_underflow(struct kvm_vcpu *vcpu)
+ {
+ 	vcpu->arch.vgic_cpu.vgic_v2.vgic_hcr &= ~GICH_HCR_UIE;
+ }
+ 
+ static void vgic_v2_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcrp)
+ {
+ 	u32 vmcr = vcpu->arch.vgic_cpu.vgic_v2.vgic_vmcr;
+ 
+ 	vmcrp->ctlr = (vmcr & GICH_VMCR_CTRL_MASK) >> GICH_VMCR_CTRL_SHIFT;
+ 	vmcrp->abpr = (vmcr & GICH_VMCR_ALIAS_BINPOINT_MASK) >> GICH_VMCR_ALIAS_BINPOINT_SHIFT;
+ 	vmcrp->bpr  = (vmcr & GICH_VMCR_BINPOINT_MASK) >> GICH_VMCR_BINPOINT_SHIFT;
+ 	vmcrp->pmr  = (vmcr & GICH_VMCR_PRIMASK_MASK) >> GICH_VMCR_PRIMASK_SHIFT;
+ }
+ 
+ static void vgic_v2_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcrp)
+ {
+ 	u32 vmcr;
+ 
+ 	vmcr  = (vmcrp->ctlr << GICH_VMCR_CTRL_SHIFT) & GICH_VMCR_CTRL_MASK;
+ 	vmcr |= (vmcrp->abpr << GICH_VMCR_ALIAS_BINPOINT_SHIFT) & GICH_VMCR_ALIAS_BINPOINT_MASK;
+ 	vmcr |= (vmcrp->bpr << GICH_VMCR_BINPOINT_SHIFT) & GICH_VMCR_BINPOINT_MASK;
+ 	vmcr |= (vmcrp->pmr << GICH_VMCR_PRIMASK_SHIFT) & GICH_VMCR_PRIMASK_MASK;
+ 
+ 	vcpu->arch.vgic_cpu.vgic_v2.vgic_vmcr = vmcr;
+ }
+ 
+ static void vgic_v2_enable(struct kvm_vcpu *vcpu)
+ {
+ 	/*
+ 	 * By forcing VMCR to zero, the GIC will restore the binary
+ 	 * points to their reset values. Anything else resets to zero
+ 	 * anyway.
+ 	 */
+ 	vcpu->arch.vgic_cpu.vgic_v2.vgic_vmcr = 0;
+ 
+ 	/* Get the show on the road... */
+ 	vcpu->arch.vgic_cpu.vgic_v2.vgic_hcr = GICH_HCR_EN;
+ }
+ 
+ static const struct vgic_ops vgic_v2_ops = {
+ 	.get_lr			= vgic_v2_get_lr,
+ 	.set_lr			= vgic_v2_set_lr,
+ 	.sync_lr_elrsr		= vgic_v2_sync_lr_elrsr,
+ 	.get_elrsr		= vgic_v2_get_elrsr,
+ 	.get_eisr		= vgic_v2_get_eisr,
+ 	.get_interrupt_status	= vgic_v2_get_interrupt_status,
+ 	.enable_underflow	= vgic_v2_enable_underflow,
+ 	.disable_underflow	= vgic_v2_disable_underflow,
+ 	.get_vmcr		= vgic_v2_get_vmcr,
+ 	.set_vmcr		= vgic_v2_set_vmcr,
+ 	.enable			= vgic_v2_enable,
+ };
+ 
+ static struct vgic_params vgic_v2_params;
+ 
+ /**
+  * vgic_v2_probe - probe for a GICv2 compatible interrupt controller in DT
+  * @node:	pointer to the DT node
+  * @ops: 	address of a pointer to the GICv2 operations
+  * @params:	address of a pointer to HW-specific parameters
+  *
+  * Returns 0 if a GICv2 has been found, with the low level operations
+  * in *ops and the HW parameters in *params. Returns an error code
+  * otherwise.
+  */
+ int vgic_v2_probe(struct device_node *vgic_node,
+ 		  const struct vgic_ops **ops,
+ 		  const struct vgic_params **params)
+ {
+ 	int ret;
+ 	struct resource vctrl_res;
+ 	struct resource vcpu_res;
+ 	struct vgic_params *vgic = &vgic_v2_params;
+ 
+ 	vgic->maint_irq = irq_of_parse_and_map(vgic_node, 0);
+ 	if (!vgic->maint_irq) {
+ 		kvm_err("error getting vgic maintenance irq from DT\n");
+ 		ret = -ENXIO;
+ 		goto out;
+ 	}
+ 
+ 	ret = of_address_to_resource(vgic_node, 2, &vctrl_res);
+ 	if (ret) {
+ 		kvm_err("Cannot obtain GICH resource\n");
+ 		goto out;
+ 	}
+ 
+ 	vgic->vctrl_base = of_iomap(vgic_node, 2);
+ 	if (!vgic->vctrl_base) {
+ 		kvm_err("Cannot ioremap GICH\n");
+ 		ret = -ENOMEM;
+ 		goto out;
+ 	}
+ 
+ 	vgic->nr_lr = readl_relaxed(vgic->vctrl_base + GICH_VTR);
+ 	vgic->nr_lr = (vgic->nr_lr & 0x3f) + 1;
+ 
+ 	ret = create_hyp_io_mappings(vgic->vctrl_base,
+ 				     vgic->vctrl_base + resource_size(&vctrl_res),
+ 				     vctrl_res.start);
+ 	if (ret) {
+ 		kvm_err("Cannot map VCTRL into hyp\n");
+ 		goto out_unmap;
+ 	}
+ 
+ 	if (of_address_to_resource(vgic_node, 3, &vcpu_res)) {
+ 		kvm_err("Cannot obtain GICV resource\n");
+ 		ret = -ENXIO;
+ 		goto out_unmap;
+ 	}
++
++	if (!PAGE_ALIGNED(vcpu_res.start)) {
++		kvm_err("GICV physical address 0x%llx not page aligned\n",
++			(unsigned long long)vcpu_res.start);
++		ret = -ENXIO;
++		goto out_unmap;
++	}
++
++	if (!PAGE_ALIGNED(resource_size(&vcpu_res))) {
++		kvm_err("GICV size 0x%llx not a multiple of page size 0x%lx\n",
++			(unsigned long long)resource_size(&vcpu_res),
++			PAGE_SIZE);
++		ret = -ENXIO;
++		goto out_unmap;
++	}
++
+ 	vgic->vcpu_base = vcpu_res.start;
+ 
+ 	kvm_info("%s@%llx IRQ%d\n", vgic_node->name,
+ 		 vctrl_res.start, vgic->maint_irq);
+ 
+ 	vgic->type = VGIC_V2;
+ 	*ops = &vgic_v2_ops;
+ 	*params = vgic;
+ 	goto out;
+ 
+ out_unmap:
+ 	iounmap(vgic->vctrl_base);
+ out:
+ 	of_node_put(vgic_node);
+ 	return ret;
+ }
diff --cc virt/kvm/arm/vgic.c
index 476d3bf,ede8f64..73eba79
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -1502,65 -1587,15 +1587,15 @@@ int kvm_vgic_hyp_init(void
  		goto out_free_irq;
  	}
  
- 	ret = of_address_to_resource(vgic_node, 2, &vctrl_res);
- 	if (ret) {
- 		kvm_err("Cannot obtain VCTRL resource\n");
- 		goto out_free_irq;
- 	}
- 
- 	vgic_vctrl_base = of_iomap(vgic_node, 2);
- 	if (!vgic_vctrl_base) {
- 		kvm_err("Cannot ioremap VCTRL\n");
- 		ret = -ENOMEM;
- 		goto out_free_irq;
- 	}
- 
- 	vgic_nr_lr = readl_relaxed(vgic_vctrl_base + GICH_VTR);
- 	vgic_nr_lr = (vgic_nr_lr & 0x3f) + 1;
- 
- 	ret = create_hyp_io_mappings(vgic_vctrl_base,
- 				     vgic_vctrl_base + resource_size(&vctrl_res),
- 				     vctrl_res.start);
- 	if (ret) {
- 		kvm_err("Cannot map VCTRL into hyp\n");
- 		goto out_unmap;
- 	}
- 
- 	if (of_address_to_resource(vgic_node, 3, &vcpu_res)) {
- 		kvm_err("Cannot obtain VCPU resource\n");
- 		ret = -ENXIO;
- 		goto out_unmap;
- 	}
 -	on_each_cpu(vgic_init_maintenance_interrupt, NULL, 1);
--
- 	if (!PAGE_ALIGNED(vcpu_res.start)) {
- 		kvm_err("GICV physical address 0x%llx not page aligned\n",
- 			(unsigned long long)vcpu_res.start);
- 		ret = -ENXIO;
- 		goto out_unmap;
- 	}
+ 	/* Callback into for arch code for setup */
+ 	vgic_arch_setup(vgic);
  
- 	if (!PAGE_ALIGNED(resource_size(&vcpu_res))) {
- 		kvm_err("GICV size 0x%llx not a multiple of page size 0x%lx\n",
- 			(unsigned long long)resource_size(&vcpu_res),
- 			PAGE_SIZE);
- 		ret = -ENXIO;
- 		goto out_unmap;
- 	}
- 
- 	vgic_vcpu_base = vcpu_res.start;
- 
- 	kvm_info("%s@%llx IRQ%d\n", vgic_node->name,
- 		 vctrl_res.start, vgic_maint_irq);
 +	on_each_cpu(vgic_init_maintenance_interrupt, NULL, 1);
 +
- 	goto out;
+ 	return 0;
  
- out_unmap:
- 	iounmap(vgic_vctrl_base);
  out_free_irq:
- 	free_percpu_irq(vgic_maint_irq, kvm_get_running_vcpus());
- out:
- 	of_node_put(vgic_node);
+ 	free_percpu_irq(vgic->maint_irq, kvm_get_running_vcpus());
  	return ret;
  }
  

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Marc Zyngier]

On Thu, Jul 31 2014 at 12:53:03 pm BST, Christoffer Dall <christofferdall@christofferdall.dk> wrote:

Hi Christoffer,

> On Thu, Jul 31, 2014 at 8:30 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>     Hi all,
>    
>     Today's linux-next merge of the kvm-arm tree got a conflict in
>     virt/kvm/arm/vgic.c between commit 63afbe7a0ac1 ("kvm: arm64: vgic: fix
>     hyp panic with 64k pages on juno platform") from Linus' tree and commit
>     8f186d522c69 ("KVM: ARM: vgic: split GICv2 backend from the main vgic
>     code") and others from the kvm-arm tree.
>    
>     I fixed it up (the latter extensively rewrites the function, so I just
>     used that) and can carry the fix as necessary (no action is required).
>
> Hmm that doesn't look correct, the checks  for
> PAGE_ALIGNED(vcpu_res.start) and PAGE_ALIGNED(resource_size(vcpu_res))
> still need to be enforced for both vgic-v2 and vgic-v3.  How do we
> provide a correct fix for Linux-next?

I've provided a resolution for GICv2 in a separate email. For GICv3, I
have the following patch in my tree, which can be added at a later time.

Thanks,

	M.

From 3eedf1d172230a117ec90832748879e88d9c3471 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Thu, 31 Jul 2014 11:42:18 +0100
Subject: [PATCH] KVM: arm64: GICv3: mandate page-aligned GICV region

Just like GICv2 was fixed in 63afbe7a0ac1
(kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform),
mandate the GICV region to be both aligned on a page boundary and
its size to be a multiple of page size.

This prevents a guest from being able to poke at regions where we
have no idea what is sitting there.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
 virt/kvm/arm/vgic-v3.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
index f01d446..1c2c8ee 100644
--- a/virt/kvm/arm/vgic-v3.c
+++ b/virt/kvm/arm/vgic-v3.c
@@ -215,6 +215,22 @@ int vgic_v3_probe(struct device_node *vgic_node,
 		ret = -ENXIO;
 		goto out;
 	}
+
+	if (!PAGE_ALIGNED(vcpu_res.start)) {
+		kvm_err("GICV physical address 0x%llx not page aligned\n",
+			(unsigned long long)vcpu_res.start);
+		ret = -ENXIO;
+		goto out;
+	}
+
+	if (!PAGE_ALIGNED(resource_size(&vcpu_res))) {
+		kvm_err("GICV size 0x%llx not a multiple of page size 0x%lx\n",
+			(unsigned long long)resource_size(&vcpu_res),
+			PAGE_SIZE);
+		ret = -ENXIO;
+		goto out;
+	}
+
 	vgic->vcpu_base = vcpu_res.start;
 	vgic->vctrl_base = NULL;
 	vgic->type = VGIC_V3;
-- 
2.0.0


-- 
Jazz is not dead. It just smells funny.

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Christoffer Dall]

On Thu, Jul 31, 2014 at 01:15:40PM +0100, Marc Zyngier wrote:
> On Thu, Jul 31 2014 at 12:53:03 pm BST, Christoffer Dall <christofferdall@christofferdall.dk> wrote:
> 
> Hi Christoffer,
> 
> > On Thu, Jul 31, 2014 at 8:30 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >     Hi all,
> >    
> >     Today's linux-next merge of the kvm-arm tree got a conflict in
> >     virt/kvm/arm/vgic.c between commit 63afbe7a0ac1 ("kvm: arm64: vgic: fix
> >     hyp panic with 64k pages on juno platform") from Linus' tree and commit
> >     8f186d522c69 ("KVM: ARM: vgic: split GICv2 backend from the main vgic
> >     code") and others from the kvm-arm tree.
> >    
> >     I fixed it up (the latter extensively rewrites the function, so I just
> >     used that) and can carry the fix as necessary (no action is required).
> >
> > Hmm that doesn't look correct, the checks  for
> > PAGE_ALIGNED(vcpu_res.start) and PAGE_ALIGNED(resource_size(vcpu_res))
> > still need to be enforced for both vgic-v2 and vgic-v3.  How do we
> > provide a correct fix for Linux-next?
> 
> I've provided a resolution for GICv2 in a separate email. For GICv3, I
> have the following patch in my tree, which can be added at a later time.
> 
The GICv3 build fix and the GICv3 fix you provided here are now both in
kvmarm/next.

Stephen, did you pick up the resolution provided by Marc for the gicv2
fix patch so that it applies to tomorrow's next/kvmarm merge?

Thanks,
-Christoffer

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Marc Zyngier]

On Thu, Jul 31 2014 at 03:23:47 PM, Christoffer Dall <cdall@cs.columbia.edu> wrote:
> On Thu, Jul 31, 2014 at 01:15:40PM +0100, Marc Zyngier wrote:
>> On Thu, Jul 31 2014 at 12:53:03 pm BST, Christoffer Dall
>> <christofferdall@christofferdall.dk> wrote:
>> 
>> Hi Christoffer,
>> 
>> > On Thu, Jul 31, 2014 at 8:30 AM, Stephen Rothwell
>> > <sfr@canb.auug.org.au> wrote:
>> >
>> >     Hi all,
>> >    
>> >     Today's linux-next merge of the kvm-arm tree got a conflict in
>> >     virt/kvm/arm/vgic.c between commit 63afbe7a0ac1 ("kvm: arm64: vgic: fix
>> >     hyp panic with 64k pages on juno platform") from Linus' tree and commit
>> >     8f186d522c69 ("KVM: ARM: vgic: split GICv2 backend from the main vgic
>> >     code") and others from the kvm-arm tree.
>> >    
>> >     I fixed it up (the latter extensively rewrites the function, so I just
>> >     used that) and can carry the fix as necessary (no action is required).
>> >
>> > Hmm that doesn't look correct, the checks  for
>> > PAGE_ALIGNED(vcpu_res.start) and PAGE_ALIGNED(resource_size(vcpu_res))
>> > still need to be enforced for both vgic-v2 and vgic-v3.  How do we
>> > provide a correct fix for Linux-next?
>> 
>> I've provided a resolution for GICv2 in a separate email. For GICv3, I
>> have the following patch in my tree, which can be added at a later time.
>> 
> The GICv3 build fix and the GICv3 fix you provided here are now both
> in kvmarm/next.

Excellent, thanks Christoffer.

Cheers,

	M.
-- 
Jazz is not dead. It just smells funny.

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

Hi Christoffer,

On Thu, 31 Jul 2014 16:23:47 +0200 Christoffer Dall <cdall@cs.columbia.edu> wrote:
>
> Stephen, did you pick up the resolution provided by Marc for the gicv2
> fix patch so that it applies to tomorrow's next/kvmarm merge?

Yes, I have.  You will need to produce the same for Linus eventually,
or do the merge yourself as I suggested.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Hi Christoffer,

On Thu, 31 Jul 2014 13:53:03 +0200 Christoffer Dall <christofferdall@christofferdall.dk> wrote:
>
> On Thu, Jul 31, 2014 at 8:30 AM, Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> 
> > Today's linux-next merge of the kvm-arm tree got a conflict in
> > virt/kvm/arm/vgic.c between commit 63afbe7a0ac1 ("kvm: arm64: vgic: fix
> > hyp panic with 64k pages on juno platform") from Linus' tree and commit
> > 8f186d522c69 ("KVM: ARM: vgic: split GICv2 backend from the main vgic
> > code") and others from the kvm-arm tree.
> >
> > I fixed it up (the latter extensively rewrites the function, so I just
> > used that) and can carry the fix as necessary (no action is required).
> >
> >
> > Hmm that doesn't look correct, the checks  for
> PAGE_ALIGNED(vcpu_res.start) and PAGE_ALIGNED(resource_size(vcpu_res))
> still need to be enforced for both vgic-v2 and vgic-v3.  How do we provide
> a correct fix for Linux-next?

Just send me a patch relative to today's linux-next (or merge
338eeb9b8318) and I will add it when I merge the kvm-arm tree on
Monday.  And don't forget to tell Linus :-)

Or you could merge commit 63afbe7a0ac1 ("kvm: arm64: vgic: fix hyp
panic with 64k pages on juno platform") from Linus' tree into the
kvm-arm tree (which is what Linus merged) and fix it up yourself - with
an appropriate comment explaining why it was done, of course.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the kvm-arm tree with Linus' tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

Hi all,

On Thu, 31 Jul 2014 22:17:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Just send me a patch relative to today's linux-next (or merge
> 338eeb9b8318) and I will add it when I merge the kvm-arm tree on
> Monday.  And don't forget to tell Linus :-)
  ^^^^^^

Actually, "tomorrow".  I forgot what day it is :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]