On 2016-08-02 07:34, Andre Przywara wrote:
> The new VGIC code is always in the VCPU entry/exit path, even when the
> actual GIC hardware initialization found the VGIC unusable (due to
> non-aligned base addresses or a missing maintenance interrupt, for
> instance).
> Since in this case the VGIC st
On Tue, Aug 02, 2016 at 04:18:46PM +0100, Marc Zyngier wrote:
> On 02/08/16 16:08, Christoffer Dall wrote:
> > On Tue, Aug 02, 2016 at 11:35:27AM +0100, Marc Zyngier wrote:
> >> On 01/08/16 19:29, Christoffer Dall wrote:
> >>> During low memory conditions, we could be dereferencing a NULL pointer
>
On 02/08/16 16:08, Christoffer Dall wrote:
> On Tue, Aug 02, 2016 at 11:35:27AM +0100, Marc Zyngier wrote:
>> On 01/08/16 19:29, Christoffer Dall wrote:
>>> During low memory conditions, we could be dereferencing a NULL pointer
>>> when vgic_add_lpi fails to allocate memory.
>>>
>>> Consider for ex
On Tue, Aug 02, 2016 at 11:35:27AM +0100, Marc Zyngier wrote:
> On 01/08/16 19:29, Christoffer Dall wrote:
> > During low memory conditions, we could be dereferencing a NULL pointer
> > when vgic_add_lpi fails to allocate memory.
> >
> > Consider for example this call sequence:
> >
> > vgic_its
On 02/08/16 15:55, Christoffer Dall wrote:
> On Tue, Aug 02, 2016 at 03:46:49PM +0100, Marc Zyngier wrote:
>> On 02/08/16 15:33, Christoffer Dall wrote:
>>> On Tue, Aug 02, 2016 at 11:12:46AM +0100, Marc Zyngier wrote:
On 02/08/16 10:40, Andre Przywara wrote:
> Hi,
>
> On 01/08/16
On Tue, Aug 02, 2016 at 03:46:49PM +0100, Marc Zyngier wrote:
> On 02/08/16 15:33, Christoffer Dall wrote:
> > On Tue, Aug 02, 2016 at 11:12:46AM +0100, Marc Zyngier wrote:
> >> On 02/08/16 10:40, Andre Przywara wrote:
> >>> Hi,
> >>>
> >>> On 01/08/16 19:20, Christoffer Dall wrote:
> On Fri,
On 02/08/16 15:33, Christoffer Dall wrote:
> On Tue, Aug 02, 2016 at 11:12:46AM +0100, Marc Zyngier wrote:
>> On 02/08/16 10:40, Andre Przywara wrote:
>>> Hi,
>>>
>>> On 01/08/16 19:20, Christoffer Dall wrote:
On Fri, Jul 22, 2016 at 06:28:50PM +0100, Marc Zyngier wrote:
> From: Andre Przy
On Wed, Jul 20, 2016 at 06:32:28PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> CPU sysregs access size is always 64 bits. MPIDR value
> passed along with reg id is used to identify the CPU.
Please provide a decent commit message along with a 200+ lines patch.
Thanks,
-Christ
On Wed, Jul 20, 2016 at 06:32:26PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> VGICv3 Distributor and Redistributor registers are accessed using
> KVM_DEV_ARM_VGIC_GRP_DIST_REGS and KVM_DEV_ARM_VGIC_GRP_DIST_REGS
> with KVM_SET_DEVICE_ATTR and KVM_GET_DEVICE_ATTR ioctls.
> The
The new VGIC code is always in the VCPU entry/exit path, even when the
actual GIC hardware initialization found the VGIC unusable (due to
non-aligned base addresses or a missing maintenance interrupt, for
instance).
Since in this case the VGIC structures aren't initialized properly, the
host kernel
On Tue, Aug 02, 2016 at 11:12:46AM +0100, Marc Zyngier wrote:
> On 02/08/16 10:40, Andre Przywara wrote:
> > Hi,
> >
> > On 01/08/16 19:20, Christoffer Dall wrote:
> >> On Fri, Jul 22, 2016 at 06:28:50PM +0100, Marc Zyngier wrote:
> >>> From: Andre Przywara
> >>>
> >>> In the GICv3 redistributor
Hi Vijaya,
On Tue, Jul 05, 2016 at 08:41:31PM +0530, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> The dist and redist regions are created and registered in
> vgic_register_dist_iodevs() and vgic_v3_init_redist_iodev()
> calls for distributor and redistributor respectively when
> vgic
On Tue, Aug 02, 2016 at 01:28:44PM +0100, Marc Zyngier wrote:
> On 02/08/16 13:23, Christoffer Dall wrote:
> > On Tue, Aug 02, 2016 at 12:10:58PM +0100, Andre Przywara wrote:
> >> According to the KVM API documentation a successful MSI injection
> >> should return a value > 0 on success.
> >> Since
According to the KVM API documentation a successful MSI injection
should return a value > 0 on success.
Return possible errors in vgic_its_trigger_msi() and report a
successful injection back to userland, while also reporting the
case where the MSI could not be delivered due to the guest not
having
On 02/08/16 13:23, Christoffer Dall wrote:
> On Tue, Aug 02, 2016 at 12:10:58PM +0100, Andre Przywara wrote:
>> According to the KVM API documentation a successful MSI injection
>> should return a value > 0 on success.
>> Since we pass the return value of vgic_its_inject_msi() directly on
>> to upp
On Tue, Aug 02, 2016 at 12:10:58PM +0100, Andre Przywara wrote:
> According to the KVM API documentation a successful MSI injection
> should return a value > 0 on success.
> Since we pass the return value of vgic_its_inject_msi() directly on
> to upper layers and userland, we need to use the same s
On 02/08/16 12:10, Andre Przywara wrote:
> According to the KVM API documentation a successful MSI injection
> should return a value > 0 on success.
> Since we pass the return value of vgic_its_inject_msi() directly on
> to upper layers and userland, we need to use the same semantics here.
> Briefl
According to the KVM API documentation a successful MSI injection
should return a value > 0 on success.
Since we pass the return value of vgic_its_inject_msi() directly on
to upper layers and userland, we need to use the same semantics here.
Briefly tested with QEMU and kvmtool on GICv3 hardware an
On 01/08/16 19:29, Christoffer Dall wrote:
> During low memory conditions, we could be dereferencing a NULL pointer
> when vgic_add_lpi fails to allocate memory.
>
> Consider for example this call sequence:
>
> vgic_its_cmd_handle_mapi
> itte->irq = vgic_add_lpi(kvm, lpi_nr);
>
On 01/08/16 19:20, Christoffer Dall wrote:
> On Fri, Jul 22, 2016 at 06:28:58PM +0100, Marc Zyngier wrote:
>> From: Andre Przywara
>>
>> When userland wants to inject an MSI into the guest, it uses the
>> KVM_SIGNAL_MSI ioctl, which carries the doorbell address along with
>> the payload and the de
On 02/08/16 10:40, Andre Przywara wrote:
> Hi,
>
> On 01/08/16 19:20, Christoffer Dall wrote:
>> On Fri, Jul 22, 2016 at 06:28:50PM +0100, Marc Zyngier wrote:
>>> From: Andre Przywara
>>>
>>> In the GICv3 redistributor there are the PENDBASER and PROPBASER
>>> registers which we did not emulate s
Hi,
On 01/08/16 19:20, Christoffer Dall wrote:
> On Fri, Jul 22, 2016 at 06:28:50PM +0100, Marc Zyngier wrote:
>> From: Andre Przywara
>>
>> In the GICv3 redistributor there are the PENDBASER and PROPBASER
>> registers which we did not emulate so far, as they only make sense
>> when having an ITS
22 matches
Mail list logo
