This patch removes config option of KVM_ARM_MAX_VCPUS,
and like other ARCHs, just choose the maximum allowed
value from hardware, and follows the reasons:
1) from distribution view, the option has to be
defined as the max allowed value because it need to
meet all kinds of virtulization
On Wed, Sep 02, 2015 at 09:21:26AM +0200, Baptiste Reynal wrote:
> On Tue, Sep 1, 2015 at 5:52 PM, Christoffer Dall
> wrote:
> > On Tue, Sep 01, 2015 at 05:32:21PM +0200, Baptiste Reynal wrote:
> >> Hi everyone,
> >>
> >> The usefullness of this patch has already been
The access is done similar to vGICv2, using KVM_DEV_ARM_VGIC_GRP_DIST_REGS
and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS with KVM_SET_DEVICE_ATTR and
KVM_GET_DEVICE_ATTR ioctls.
Some registers are 64-bit wide according to the specification.
KVM_DEV_ARM_VGIC_64BIT flag is introduced, allowing to perform
This patchset adds necessary userspace API in order to support vGICv3 live
migration. GICv3 registers are accessed using device attribute ioctls,
similar to GICv2.
v1 => v2:
- Do not use generic register get/set API for CPU interface, use only
device attributes.
- Introduce size specifier for
Replace Rt with data pointer in struct sys_reg_params. This will allow to
reuse system register handling code in implementation of vGICv3 CPU
interface access API. Additionally, got rid of "massive hack"
in kvm_handle_cp_64().
Signed-off-by: Pavel Fedin
---
The access is done similar to GICv2, using KVM_DEV_ARM_VGIC_GRP_CPU_REGS
group, however attribute ID encodes corresponding system register. Access
size is always 64 bits.
Since CPU interface state actually affects only a single vCPU, no vGIC
locking is done. Just made sure that the vCPU is not
Separate all implementation-independent code in vgic_attr_regs_access()
and move it to vgic.c. This will allow to reuse this code for vGICv3
implementation.
Signed-off-by: Pavel Fedin
---
virt/kvm/arm/vgic-v2-emul.c | 126 +---
On Tue, Sep 1, 2015 at 5:52 PM, Christoffer Dall
wrote:
> On Tue, Sep 01, 2015 at 05:32:21PM +0200, Baptiste Reynal wrote:
>> Hi everyone,
>>
>> The usefullness of this patch has already been discussed during the
>> first releases
>>
On Mon, Aug 10, 2015 at 09:26:03PM +0800, Zhichao Huang wrote:
> As we're about to implement a lazy world switch for debug registers,
> we add a function reading the break/watch control variables directly to
> indicate whether the host has enabled any break/watch points or not.
>
> Signed-off-by:
On Mon, Aug 10, 2015 at 09:26:07PM +0800, Zhichao Huang wrote:
> Enable trapping of the debug registers unconditionally, allowing guests to
> use the debug infrastructure.
>
> Signed-off-by: Zhichao Huang
> Reviewed-by: Christoffer Dall
>
On Wed, 2015-09-02 at 11:49 +0200, Baptiste Reynal wrote:
> On Wed, Sep 2, 2015 at 11:21 AM, Christoffer Dall
> wrote:
> > On Wed, Sep 02, 2015 at 09:21:26AM +0200, Baptiste Reynal wrote:
> >> On Tue, Sep 1, 2015 at 5:52 PM, Christoffer Dall
> >>
On Mon, Aug 10, 2015 at 09:25:58PM +0800, Zhichao Huang wrote:
> Add handlers for all the 32-bit debug registers.
>
> Signed-off-by: Zhichao Huang
Reviewed-by: Christoffer Dall
___
kvmarm mailing
On Mon, Aug 10, 2015 at 09:26:04PM +0800, Zhichao Huang wrote:
> Every guest entry, we need to keep track of host use of the debug
> registers.
>
> We only call the function upon guest entry, after preempt_disable()
> and local_irq_disable(), so there is no race for it.
what about on SMP? It
On Mon, Aug 10, 2015 at 09:26:05PM +0800, Zhichao Huang wrote:
> We trap debug register accesses from guest all the time, and read the
> BCR/WCR to indicate whether the guest has enabled any break/watch points
> or not.
>
> Signed-off-by: Zhichao Huang
> ---
>
On Mon, Aug 10, 2015 at 03:20:59PM +0200, Eric Auger wrote:
> This function returns whether the IRQ is active at irqchip level or
> VFIO masked. If either is true, it is considered the IRQ is active.
> Currently there is no way to differentiate userspace masked IRQ from
> automasked IRQ. There
On Mon, Aug 10, 2015 at 03:21:01PM +0200, Eric Auger wrote:
> From: Marc Zyngier
>
> So far, the only use of the HW interrupt facility was the timer,
> implying that the active state is context-switched for each vcpu,
> as the device is is shared across all vcpus.
>
> This
On Mon, Aug 10, 2015 at 03:21:00PM +0200, Eric Auger wrote:
> This patch populates the IRQ bypass callacks:
> - stop/start producer simply consist in disabling/enabling the host irq
> - add/del consumer: basically set the automasked flag to false/true
>
> Signed-off-by: Eric Auger
On Mon, Aug 10, 2015 at 03:21:03PM +0200, Eric Auger wrote:
> Implements kvm_vgic_[set|unset]_forward.
>
> Handle low-level VGIC programming: physical IRQ/guest IRQ mapping,
> list register cleanup, VGIC state machine. Also interacts with
> the irqchip.
>
> Signed-off-by: Eric Auger
On Mon, Aug 10, 2015 at 03:20:54PM +0200, Eric Auger wrote:
> This series allows to set ARM IRQ forwarding between a VFIO platform
> device physical IRQ and a guest virtual IRQ. The link is coordinated
> by the IRQ bypass manager.
>
> The principle is the VFIO platform driver registers an IRQ
On Mon, Aug 10, 2015 at 09:25:53PM +0800, Zhichao Huang wrote:
> Hardware debugging in guests is not intercepted currently, it means
> that a malicious guest can bring down the entire machine by writing
> to the debug registers.
>
> This patch enable trapping of all debug registers, preventing
On Wed, Sep 2, 2015 at 6:25 PM, Christoffer Dall
wrote:
> On Wed, Sep 02, 2015 at 02:31:21PM +0800, Ming Lei wrote:
>> This patch removes config option of KVM_ARM_MAX_VCPUS,
>> and like other ARCHs, just choose the maximum allowed
>> value from hardware, and follows
On 13 August 2015 at 13:33, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> This series enables the 16K page size support on Linux for arm64.
> This series adds support for 48bit VA(4 level), 47bit VA(3 level) and
> 36bit VA(2 level) with
On 02/09/15 10:55, Ard Biesheuvel wrote:
On 13 August 2015 at 13:33, Suzuki K. Poulose wrote:
From: "Suzuki K. Poulose"
Patches 1-7 cleans up the kernel page size handling code.
Patches 8-11 Fixes some issues with the KVM bits, mainly the
On Wed, Sep 02, 2015 at 02:31:21PM +0800, Ming Lei wrote:
> This patch removes config option of KVM_ARM_MAX_VCPUS,
> and like other ARCHs, just choose the maximum allowed
> value from hardware, and follows the reasons:
>
> 1) from distribution view, the option has to be
> defined as the max
On Wed, Sep 02, 2015 at 11:49:12AM +0200, Baptiste Reynal wrote:
> On Wed, Sep 2, 2015 at 11:21 AM, Christoffer Dall
> wrote:
> > On Wed, Sep 02, 2015 at 09:21:26AM +0200, Baptiste Reynal wrote:
> >> On Tue, Sep 1, 2015 at 5:52 PM, Christoffer Dall
> >>
On 13 August 2015 at 19:29, Catalin Marinas wrote:
> On Thu, Aug 13, 2015 at 03:45:07PM +0100, Suzuki K. Poulose wrote:
>> On 13/08/15 13:28, Steve Capper wrote:
>> >On 13 August 2015 at 12:34, Suzuki K. Poulose
>> >wrote:
>> >> __enable_mmu:
>>
On 2 September 2015 at 11:48, Ard Biesheuvel wrote:
> On 13 August 2015 at 19:29, Catalin Marinas wrote:
>> On Thu, Aug 13, 2015 at 03:45:07PM +0100, Suzuki K. Poulose wrote:
>>> On 13/08/15 13:28, Steve Capper wrote:
>>> >On 13 August 2015 at
On Mon, Aug 10, 2015 at 09:25:56PM +0800, Zhichao Huang wrote:
> As we're about to trap a bunch of CP14 registers, let's rework
> the CP15 handling so it can be generalized and work with multiple
> tables.
>
> We stop trapping access here, because we haven't finished our trap
> handlers. We will
On Mon, Aug 10, 2015 at 09:26:02PM +0800, Zhichao Huang wrote:
> Implement switching of the debug registers. While the number
> of registers is massive, CPUs usually don't implement them all
> (A15 has 6 breakpoints and 4 watchpoints, which gives us a total
> of 22 registers "only").
>
>
On Mon, Aug 10, 2015 at 09:26:01PM +0800, Zhichao Huang wrote:
> Redefine kvm_cpu_context_t as a new struct that include the cp14 states,
> which we used to save the host cp14 states.
>
> Signed-off-by: Zhichao Huang
> ---
> arch/arm/include/asm/kvm_host.h | 6 +-
>
30 matches
Mail list logo