Hugetlb VMAs are not mergeable, that means a VMA couldn't have VM_HUGETLB and
VM_MERGEABLE been set in the same time. So we use VM_HUGETLB to indicate new
mergeable VMAs. Because of that a VMA which has VM_HUGETLB been set is a hugetlb
VMA only if it doesn't have VM_MERGEABLE been set in the same t
Hugetlb VMAs are not mergeable, that means a VMA couldn't have VM_HUGETLB and
VM_MERGEABLE been set in the same time. So we use VM_HUGETLB to indicate new
mergeable VMAs. Because of that a VMA which has VM_HUGETLB been set is a hugetlb
VMA only if it doesn't have VM_MERGEABLE been set in the same t
I observe that it is unlikely for KSM to merge new pages from an area
that has already been scanned twice on Android mobile devices, so it's
a waste of power to scan these areas in high frequency. In this patchset,
a defer mechanism is introduced which is borrowed from page compaction to KSM.
A ne
Hugetlb VMAs are not mergeable, that means a VMA couldn't have VM_HUGETLB and
VM_MERGEABLE been set in the same time. So we use VM_HUGETLB to indicate new
mergeable VMAs. Because of that a VMA which has VM_HUGETLB been set is a hugetlb
VMA only if it doesn't have VM_MERGEABLE been set in the same t
Hugetlb VMAs are not mergeable, that means a VMA couldn't have VM_HUGETLB and
VM_MERGEABLE been set in the same time. So we use VM_HUGETLB to indicate new
mergeable VMAs. Because of that a VMA which has VM_HUGETLB been set is a hugetlb
VMA only if it doesn't have VM_MERGEABLE been set in the same t
Hugetlb VMAs are not mergeable, that means a VMA couldn't have VM_HUGETLB and
VM_MERGEABLE been set in the same time. So we use VM_HUGETLB to indicate new
mergeable VMAs. Because of that a VMA which has VM_HUGETLB been set is a hugetlb
VMA only if it doesn't have VM_MERGEABLE been set in the same t
I observe that it is unlikely for KSM to merge new pages from an area
that has already been scanned twice on Android mobile devices, so it's
a waste of power to continue to scan these areas in high frequency.
In this patch a defer mechanism is introduced which is borrowed from
page compaction to KS
This patch creates a dispatch function to support virt GIC probing
in both device tree (DT) and ACPI environment. kvm_vgic_hyp_init()
will probe DT first. If failed, it will try ACPI.
Signed-off-by: Wei Huang
---
include/kvm/arm_vgic.h | 18 +-
virt/kvm/arm/vgic-v2.c | 8 ---
This patches enables ACPI support for KVM virtual GICv2. KVM parses
ACPI table for virt GIC related information and initializes resources.
Signed-off-by: Alexander Spyridaki
Signed-off-by: Wei Huang
---
virt/kvm/arm/vgic-v2.c | 50 +-
1 file chang
Initial ACPI support for ARM64 has been accepted into Linux kernel recently.
Now it is a good time to re-visit ACPI support for KVM. This patchset
enables ACPI for both arch_timer and vGIC by probing related ACPI tables
and does necessary initialization.
Note that Alexander Spyridaki submitted sim
This patches enables ACPI support for KVM virtual GICv3. KVM parses
ACPI table for virt GIC related information and initializes resources.
Signed-off-by: Wei Huang
---
virt/kvm/arm/vgic-v3.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --gi
This patches enables ACPI support for KVM virtual arch timer. It allows
KVM to parse ACPI table for arch timer PPI when DT table is not present.
Signed-off-by: Alexander Spyridaki
Signed-off-by: Wei Huang
---
virt/kvm/arm/arch_timer.c | 75 +++
1 file
There are two GICs (GICv2 and GICv3) supported by KVM. So it is necessary
to find out GIC version before calling ACPI probing functions defined
in vgic-v2.c and vgic-v3.c.
This patch detects GIC version by checking gic_version field of GIC
distributor, which was defined since ACPI 6.0. In case of
Rajat Jain writes:
> Fix the following warning:
>
> arch/x86/kvm/emulate.c: In function '__do_insn_fetch_bytes':
> arch/x86/kvm/emulate.c:814:47: warning: 'linear' may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> arch/x86/kvm/emulate.c:793:16: note: 'linear' was declared he
Fix the following warning:
arch/x86/kvm/emulate.c: In function '__do_insn_fetch_bytes':
arch/x86/kvm/emulate.c:814:47: warning: 'linear' may be used uninitialized in
this function [-Wmaybe-uninitialized]
arch/x86/kvm/emulate.c:793:16: note: 'linear' was declared here
Signed-off-by: Rajat Jain
S
Fix the following warning:
arch/x86/kvm/emulate.c: In function '__do_insn_fetch_bytes':
arch/x86/kvm/emulate.c:814:47: warning: 'linear' may be used uninitialized in
this function [-Wmaybe-uninitialized]
arch/x86/kvm/emulate.c:793:16: note: 'linear' was declared here
Signed-off-by: Rajat Jain
S
On 06/08/2015 04:35 AM, Christoffer Dall wrote:
> On Fri, Jun 05, 2015 at 05:24:07AM -0700, Mario Smarduch wrote:
>> On 06/02/2015 02:27 AM, Christoffer Dall wrote:
>>> On Mon, Jun 01, 2015 at 08:48:22AM -0700, Mario Smarduch wrote:
On 05/30/2015 11:59 PM, Christoffer Dall wrote:
> Hi Mari
On 05/06/15 16:21, Eric Auger wrote:
> From: Kim Phillips
>
> The KVM-VFIO device is used by the QEMU VFIO device. It is used to
> record the list of in-use VFIO groups so that KVM can manipulate
> them.
>
> Signed-off-by: Kim Phillips
> Signed-off-by: Eric Auger
>
> ---
>
> - previously inc
On 09/06/15 15:43, Christoffer Dall wrote:
> On Mon, Jun 08, 2015 at 06:50:08PM +0100, Marc Zyngier wrote:
>> Hi Christoffer,
>>
>> On 28/05/15 19:49, Christoffer Dall wrote:
>>> Until now we have been calling kvm_guest_exit after re-enabling
>>> interrupts when we come back from the guest, but thi
On 05/29/2015 11:53 AM, Andre Przywara wrote:
> As the actual LPI number in a guest can be quite high, but is mostly
> assigned using a very sparse allocation scheme, bitmaps and arrays
> for storing the virtual interrupt status are a waste of memory.
> We use our equivalent of the "Interrupt Trans
Reviewed-by: Eric Auger
On 05/29/2015 11:53 AM, Andre Przywara wrote:
> The GICv3 Interrupt Translation Service (ITS) uses tables in memory
> to allow a sophisticated interrupt routing. It features device tables,
> an interrupt table per device and a table connecting "collections" to
> actual CPUs
On Mon, Jun 08, 2015 at 06:50:08PM +0100, Marc Zyngier wrote:
> Hi Christoffer,
>
> On 28/05/15 19:49, Christoffer Dall wrote:
> > Until now we have been calling kvm_guest_exit after re-enabling
> > interrupts when we come back from the guest, but this has the
> > unfortunate effect that CPU time
On 09/06/15 14:21, Alex Bennée wrote:
>
> Marc Zyngier writes:
>
>> Now that struct vgic_lr supports the LR_HW bit and carries a hwirq
>> field, we can encode that information into the list registers.
>>
>> This patch provides implementations for both GICv2 and GICv3.
>>
>> Signed-off-by: Marc Z
Zhichao Huang writes:
> Add #ifndef __ASSEMBLY__ in hw_breakpoint.h, in order to use
> the ARM_DSCR_MDBGEN macro from KVM assembly code.
>
> Signed-off-by: Zhichao Huang
Reviewed-by: Alex Bennée
> ---
> arch/arm/include/asm/hw_breakpoint.h | 54
> +++-
> 1 f
Reviewed-by: Eric Auger
On 05/29/2015 11:53 AM, Andre Przywara wrote:
> Add emulation for some basic MMIO registers used in the ITS emulation.
> This includes:
> - GITS_{CTLR,TYPER,IIDR}
> - ID registers
> - GITS_{CBASER,CREAD,CWRITER}
CREADR
> those implement the ITS command buffer handling
>
Marc Zyngier writes:
> Now that struct vgic_lr supports the LR_HW bit and carries a hwirq
> field, we can encode that information into the list registers.
>
> This patch provides implementations for both GICv2 and GICv3.
>
> Signed-off-by: Marc Zyngier
> ---
> include/linux/irqchip/arm-gic-v3.
Marc Zyngier writes:
> As we're about to cram more information in the vgic_lr structure
> (HW interrupt number and additional state information), we switch
> to a layout similar to the HW's:
>
> - use bitfields to save space (we don't need more than 10 bits
> to represent the irq numbers)
> -
Marc Zyngier writes:
> As we're about to introduce some serious GIC-poking to the vgic code,
> it is important to make sure that we're going to poke the part of
> the GIC that belongs to the CPU we're about to run on (otherwise,
> we'd end up with some unexpected interrupts firing)...
>
> Introd
Hi, contrary to my boasting in the cover letter I managed to
accidentially drop the fix for the GIC device initialization error
handling Will requested from this series.
If we fail the GIC initialization sequence at some point, we should
make sure to not let the gic_fd initialized, so that subseque
Marc Zyngier writes:
> As we now inject the timer interrupt when we're about to enter
> the guest, it makes a lot more sense to make sure this happens
> before the vgic code queues the pending interrupts.
>
> Otherwise, we get the interrupt on the following exit, which is
> not great for latency
Zhichao Huang writes:
> 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.
>
> Signed-off-by: Zhichao Huang
> ---
> arch/arm/kvm/coproc.c | 176
> ++---
> arc
Zhichao Huang writes:
> pm_fake doesn't quite describe what the handler does (ignoring writes
> and returning 0 for reads).
>
> As we're about to use it (a lot) in a different context, rename it
> with a (admitedly cryptic) name that make sense for all users.
>
> Signed-off-by: Zhichao Huang
R
On 07/06/15 14:40, zichao wrote:
> Hi, Marc,
>
> On 2015/6/1 18:56, Marc Zyngier wrote:
>> Hi Zhichao,
>>
>> On 31/05/15 05:27, 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
>>> t
On 05/29/2015 11:53 AM, Andre Przywara wrote:
> The ARM GICv3 ITS emulation code goes into a separate file, but
> needs to be connected to the GICv3 emulation, of which it is an
> option.
> Introduce the skeletton with function stubs to be filled later.
skeleton
> Introduce the basic ITS data struc
On 05/29/2015 11:53 AM, Andre Przywara wrote:
> 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. In preparation for that emulate those MMIO
> accesses by storing the 64-bit data written into i
Reviewed-by: Eric Auger
On 05/29/2015 11:53 AM, Andre Przywara wrote:
> Currently we destroy the VGIC emulation in one function that cares for
> all emulated models. The ITS emulation will require some
> differentiation, so introduce a per-emulation-model destroy method.
> Use it for a tiny GICv3
On 05/29/2015 11:53 AM, Andre Przywara wrote:
> The ARM GICv3 ITS controller requires a separate register frame to
> cover ITS specific registers. Add a new VGIC address type and store
> the address in a field in the vgic_dist structure.
> Provide a function to check whether userland has provided t
Reviewed-by: Eric Auger
On 05/29/2015 11:53 AM, Andre Przywara wrote:
> The ARM GICv3 ITS MSI controller requires a device ID to be able to
> assign the proper interrupt vector. On real hardware, this ID is
> sampled from the bus. To be able to emulate an ITS controller, extend
> the KVM MSI inter
On 06/08/2015 12:54 PM, Pavel Fedin wrote:
> Hi!
>
>> I'm afraid this is not enough. A write to GICR_TRANSLATER (DID+EID)
>> results in a (LPI,CPU) pair. Can you easily express the CPU part in
>> irqfd (this is a genuine question, I'm not familiar enough with that
>> part of the core)?
Currently
39 matches
Mail list logo
