We are doing an unnecessary stack push/pop operation when restoring
the guest registers x0-x18 in __guest_enter(). This patch saves the
two instructions by using x18 as a base register. No need to store
the vcpu context pointer in stack because it is redundant and not
being used anywhere, the same
KVM devices were manipulating list data structures without any form of
synchronization, and some implementations of the create operations also
suffered from a lack of synchronization.
Now when we've split the xics create operation into create and init, we
can hold the kvm->lock mutex while calling
As we are about to hold the kvm->lock during the create operation on KVM
devices, we should move the call to xics_debugfs_init into its own
function, since holding a mutex over extended amounts of time might not
be a good idea.
Introduce an init operation on the kvm_device_ops struct which cannot
Currently accesses the kvm->devices list is not synchronized by any
mechanism which can potentially lead to data corruption. Further, a
number of the create operations on the individual devices are racy and
would allow creation of multiple devices, opposite to the intention.
Factor out portions o
On 09/08/2016 16:49, Christoffer Dall wrote:
> On Tue, Aug 09, 2016 at 03:16:26PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 09/08/2016 14:55, Christoffer Dall wrote:
>>> On Tue, Aug 09, 2016 at 02:37:43PM +0200, Paolo Bonzini wrote:
On 09/08/2016 14:20, Christoffer Dall wrote:
>
On Tue, Aug 09, 2016 at 03:16:26PM +0200, Paolo Bonzini wrote:
>
>
> On 09/08/2016 14:55, Christoffer Dall wrote:
> > On Tue, Aug 09, 2016 at 02:37:43PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 09/08/2016 14:20, Christoffer Dall wrote:
> >>> KVM devices were manipulating list data structures
On Tue, Aug 09, 2016 at 10:54:29AM +0100, Andre Przywara wrote:
> When userspace provides the doorbell address for an MSI to be
> injected into the guest, we find a KVM device which feels responsible.
> Lets check that this device is really an emulated ITS before we make
> real use of the container
On Mon, Aug 08, 2016 at 05:29:28PM +0100, Andre Przywara wrote:
> 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 t
On 09/08/2016 14:55, Christoffer Dall wrote:
> On Tue, Aug 09, 2016 at 02:37:43PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 09/08/2016 14:20, Christoffer Dall wrote:
>>> KVM devices were manipulating list data structures without any form of
>>> synchronization, and some implementations of the creat
Hi,
On 09/08/16 12:16, Christoffer Dall wrote:
> There are two problems with the current implementation of the MMIO
> handlers for the propbaser and pendbaser:
>
> First, the write to the value itself is not guaranteed to be an atomic
> 64-bit write so two concurrent writes to the structure field
Hi,
On 09/08/16 12:16, Christoffer Dall wrote:
> Right now the following sequence of events can happen:
>
> 1. Thread X calls vgic_put_irq
> 2. Thread Y calls vgic_add_lpi
> 3. Thread Y gets lpi_list_lock
> 4. Thread X drops the ref count to 0 and blocks on lpi_list_lock
> 5. Thread Y f
On Tue, Aug 09, 2016 at 02:37:43PM +0200, Paolo Bonzini wrote:
>
>
> On 09/08/2016 14:20, Christoffer Dall wrote:
> > KVM devices were manipulating list data structures without any form of
> > synchronization, and some implementations of the create operations also
> > suffered from a lack of sync
On 09/08/2016 14:20, Christoffer Dall wrote:
> KVM devices were manipulating list data structures without any form of
> synchronization, and some implementations of the create operations also
> suffered from a lack of synchronization.
>
> Now when we've split the xics create operation into creat
Currently accesses the kvm->devices list is not synchronized by any
mechanism which can potentially lead to data corruption. Further, a
number of the create operations on the individual devices are racy and
would allow creation of multiple devices, opposite to the intention.
Factor out portions o
As we are about to hold the kvm->lock during the create operation on KVM
devices, we should move the call to xics_debugfs_init into its own
function, since holding a mutex over extended amounts of time might not
be a good idea.
Introduce an init operation on the kvm_device_ops struct which cannot
KVM devices were manipulating list data structures without any form of
synchronization, and some implementations of the create operations also
suffered from a lack of synchronization.
Now when we've split the xics create operation into create and init, we
can hold the kvm->lock mutex while calling
On Tue, Aug 09, 2016 at 12:19:53PM +0100, Andre Przywara wrote:
> Hi,
>
> On 09/08/16 11:30, Christoffer Dall wrote:
> > On Mon, Aug 08, 2016 at 02:30:38PM +0100, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 03/08/16 17:13, Christoffer Dall wrote:
> >>> There are two problems with the current imple
On 9 August 2016 at 11:58, wrote:
> From: Vijaya Kumar K
>
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> http://lists.infradead.org/pipermail/linux-arm-ker
Hi,
On 09/08/16 11:30, Christoffer Dall wrote:
> On Mon, Aug 08, 2016 at 02:30:38PM +0100, Andre Przywara wrote:
>> Hi,
>>
>> On 03/08/16 17:13, Christoffer Dall wrote:
>>> There are two problems with the current implementation of the MMIO
>>> handlers for the propbaser and pendbaser:
>>>
>>> Firs
There are two problems with the current implementation of the MMIO
handlers for the propbaser and pendbaser:
First, the write to the value itself is not guaranteed to be an atomic
64-bit write so two concurrent writes to the structure field could be
intermixed.
Second, because we do a read-modify
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);
update_lpi_config(kvm, itte->irq, NULL);
ret
Right now the following sequence of events can happen:
1. Thread X calls vgic_put_irq
2. Thread Y calls vgic_add_lpi
3. Thread Y gets lpi_list_lock
4. Thread X drops the ref count to 0 and blocks on lpi_list_lock
5. Thread Y finds the irq via the lpi_list_lock, raises the ref
count
Here are three small fixes resulting from looking at the pull request of
kvmarm/next into kvm/next.
They basically deal with corner cases in the reference count handling and
atomicity issues.
See the individual patches for changelogs.
Christoffer Dall (3):
KVM: arm64: vgic-its: Handle errors f
From: Vijaya Kumar K
VGICv3 CPU interface registers are accessed using
KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
as 64-bit. The cpu MPIDR value is passed along with register id.
is used to identify the cpu for registers access.
The version of VGIC v3 specification is defin
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.
These registers are accessed as 32-bit and cpu mpidr
value passed along with register o
From: Vijaya Kumar K
vgic_attr_regs_access() handles only 32-bit register
value. Pass u64 as parameter and locally handle 32-bit
reads and writes depending on attribute group.
Signed-off-by: Vijaya Kumar K
---
virt/kvm/arm/vgic/vgic-kvm-device.c | 26 +++---
1 file changed,
From: Vijaya Kumar K
In order to implement vGICv3 CPU interface access, we will need to perform
table lookup of system registers. We would need both index_to_params() and
find_reg() exported for that purpose, but instead we export a single
function which combines them both.
Signed-off-by: Pavel
From: Vijaya Kumar K
This patchset adds API for saving and restoring
of VGICv3 registers to support live migration with new vgic feature.
This API definition is as per version of VGICv3 specification
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
To test live migrati
On Tue, Aug 09, 2016 at 12:30:12PM +0200, Christoffer Dall wrote:
> On Mon, Aug 08, 2016 at 02:30:38PM +0100, Andre Przywara wrote:
> > Hi,
> >
> > On 03/08/16 17:13, Christoffer Dall wrote:
> > > There are two problems with the current implementation of the MMIO
> > > handlers for the propbaser a
On Mon, Aug 08, 2016 at 02:30:38PM +0100, Andre Przywara wrote:
> Hi,
>
> On 03/08/16 17:13, Christoffer Dall wrote:
> > There are two problems with the current implementation of the MMIO
> > handlers for the propbaser and pendbaser:
> >
> > First, the write to the value itself is not guaranteed
On Mon, Aug 08, 2016 at 12:20:14PM +0100, Andre Przywara wrote:
> Hi,
>
> On 03/08/16 17:13, Christoffer Dall wrote:
> > Right now the following sequence of events can happen:
> >
> > 1. Thread X calls vgic_put_irq
> > 2. Thread Y calls vgic_add_lpi
> > 3. Thread Y gets lpi_list_lock
> >
On Mon, Aug 08, 2016 at 12:00:50PM +0100, Andre Przywara wrote:
> Hi,
>
> On 03/08/16 17:13, 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:
> >
> >
When userspace provides the doorbell address for an MSI to be
injected into the guest, we find a KVM device which feels responsible.
Lets check that this device is really an emulated ITS before we make
real use of the container_of-ed pointer.
Signed-off-by: Andre Przywara
---
virt/kvm/arm/vgic/v
Hi Andre,
On 08/08/2016 17:45, Andre Przywara wrote:
> Currently we register an ITS device upon userland issuing the CTLR_INIT
> ioctl to mark initialization of the ITS as done.
> This deviates from the initialization sequence of the existing GIC
> devices and does not play well with the way QEMU
Hi Andre,
On 08/08/2016 18:29, Andre Przywara wrote:
> 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 w
35 matches
Mail list logo
