Re: [PATCH v4 3/5] target-arm: kvm64 sync FP register state

On 16 March 2015 at 11:01, Alex Bennée alex.ben...@linaro.org wrote: For migration to work we need to sync all of the register state. This is especially noticeable when GCC starts using FP registers as spill registers even with integer programs. Signed-off-by: Alex Bennée

Re: [PATCH v4 4/5] target-arm: kvm64 fix save/restore of SPSR regs

On 17 March 2015 at 19:04, Christoffer Dall christoffer.d...@linaro.org wrote: On Tue, Mar 17, 2015 at 04:18:16PM +, Peter Maydell wrote: Note that this code is implicitly relying on the ordering of register banks defined by the bank_number() function, which is a bit icky. right, I

Re: [PATCH] target-arm: Store SPSR_EL1 state in banked_spsr[1] (SPSR_svc)

On 17 March 2015 at 19:22, Christoffer Dall christoffer.d...@linaro.org wrote: On Tue, Mar 17, 2015 at 07:19:35PM +, Peter Maydell wrote: The AArch64 SPSR_EL1 register is architecturally mandated to be mapped to the AArch32 SPSR_svc register. This means its state should live in QEMU's env

Re: [PATCH 6/6] target-arm/cpu.h: document why env-spsr exists

On 25 February 2015 at 16:02, Alex Bennée alex.ben...@linaro.org wrote: I was getting very confused about the duplication of state. Perhaps we should just get rid of env-spsr and use helpers that understand the banking? I've already disagreed with this. I would suggest putting tentative

Re: [PATCH v4 3/3] hw/intc/arm_gic: Initialize the vgic in the realize function

to complete initialization of the VGIC now */ Otherwise Reviewed-by: Peter Maydell peter.mayd...@linaro.org thanks -- PMM ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5] hw/intc/arm_gic: Initialize the vgic in the realize function

On 11 March 2015 at 17:17, Eric Auger eric.au...@linaro.org wrote: This patch forces vgic initialization in the vgic realize function. It uses a new group/attribute that allows such operation: KVM_DEV_ARM_VGIC_GRP_CTRL/KVM_DEV_ARM_VGIC_CTRL_INIT This earlier initialization allows, for

Re: [PATCH v2 1/6] target-arm: kvm: save/restore mp state

On 4 March 2015 at 14:35, Alex Bennée alex.ben...@linaro.org wrote: This adds the saving and restore of the current Multi-Processing state of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of potential states for x86 we only use two for ARM. Either the process is running or

Re: [PATCH v2 3/6] hw/char: pl011 don't keep setting the IRQ if nothing changed

On 4 March 2015 at 14:35, Alex Bennée alex.ben...@linaro.org wrote: While observing KVM traces I can see additional IRQ calls on pretty much every MMIO access which is just plain inefficient. Only update the QEMU IRQ level if something has actually changed from last time. Otherwise we may be

Re: [PATCH v2 3/6] hw/char: pl011 don't keep setting the IRQ if nothing changed

On 12 March 2015 at 15:51, Peter Maydell peter.mayd...@linaro.org wrote: On 4 March 2015 at 14:35, Alex Bennée alex.ben...@linaro.org wrote: While observing KVM traces I can see additional IRQ calls on pretty much every MMIO access which is just plain inefficient. Only update the QEMU IRQ

Re: [Qemu-devel] [PATCH v5 1/6] target-arm: Store SPSR_EL1 state in banked_spsr[1] (SPSR_svc)

On 24 March 2015 at 14:32, Greg Bellows greg.bell...@linaro.org wrote: On Mon, Mar 23, 2015 at 12:05 PM, Alex Bennée alex.ben...@linaro.org wrote: From: Peter Maydell peter.mayd...@linaro.org @@ -523,7 +523,7 @@ void aarch64_cpu_do_interrupt(CPUState *cs) aarch64_save_sp(env

Re: [PATCH v5 6/6] target-arm: cpu.h document why env-spsr exists

On 23 March 2015 at 17:05, Alex Bennée alex.ben...@linaro.org wrote: I was getting very confused about the duplication of state so wanted to make it explicit. Signed-off-by: Alex Bennée alex.ben...@linaro.org diff --git a/target-arm/cpu.h b/target-arm/cpu.h index 083211c..6dc1799 100644

Re: [RFC/RFT PATCH 0/3] arm64: KVM: work around incoherency with uncached guest mappings

On 5 March 2015 at 20:04, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Mar 05, 2015 at 11:12:22AM +0100, Paolo Bonzini wrote: On 04/03/2015 18:28, Catalin Marinas wrote: Can you add that property to the device tree for PCI devices too? Yes but not with mainline yet:

Re: kvm [2087]: load/store instruction decoding not implemented

On 24 February 2015 at 20:59, Richard W.M. Jones rjo...@redhat.com wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1194366 Has anyone seen this KVM error? Or have suggestions how to debug it further? kvm [2028]: load/store instruction decoding not implemented This is a fairly common

Re: kvm [2087]: load/store instruction decoding not implemented

On 24 February 2015 at 21:29, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Feb 24, 2015 at 09:15:18PM +0900, Peter Maydell wrote: Complex insns are things like load-multiple (there's a complete list in the ARM ARM somewhere). Generally this indicates a guest bug because you really

Re: kvm [2087]: load/store instruction decoding not implemented

On 24 February 2015 at 23:55, Christoffer Dall christoffer.d...@linaro.org wrote: IPA is the Intermediate Physical Address (i.e. your guest physical address). As far as I can tell from looking at the QEMU virt memory map, 0x3x does not belong to any devices or RAM on the board

Re: [PATCH v2 3/4] target-arm: kvm - support for single step

On 21 April 2015 at 13:56, Alex Bennée alex.ben...@linaro.org wrote: Peter Maydell peter.mayd...@linaro.org writes: switch (hsr_ec) { +case HSR_EC_SOFT_STEP: +if (cs-singlestep_enabled) { +return true; +} else { +error_report(Came out

Re: [PATCH v2 4/4] target-arm: kvm - add support for HW assisted debug

On 31 March 2015 at 16:40, Alex Bennée alex.ben...@linaro.org wrote: From: Alex Bennée a...@bennee.com This adds basic support for HW assisted debug. The ioctl interface to KVM allows us to pass an implementation defined number of break and watch point registers. When KVM_GUESTDBG_USE_HW_BP

Re: [PATCH v2 3/4] target-arm: kvm - support for single step

On 31 March 2015 at 16:40, Alex Bennée alex.ben...@linaro.org wrote: This adds support for single-step. There isn't much to do on the QEMU side as after we set-up the request for single step via the debug ioctl it is all handled within the kernel. Signed-off-by: Alex Bennée

Re: [PATCH v2 0/3] Add support for for GICv2m and MSIs to arm-virt

On 27 April 2015 at 18:31, Christoffer Dall christoffer.d...@linaro.org wrote: Now when we have a host generic PCIe controller in the virt board, it would be nice to be able to use MSIs so that we can eventually enable VHOST with KVM. With these patches you can use MSIs with TCG and with KVM,

Re: [PATCH v2 0/3] Add support for for GICv2m and MSIs to arm-virt

On 6 May 2015 at 17:33, Peter Maydell peter.mayd...@linaro.org wrote: On 27 April 2015 at 18:31, Christoffer Dall christoffer.d...@linaro.org wrote: Now when we have a host generic PCIe controller in the virt board, it would be nice to be able to use MSIs so that we can eventually enable

Re: [RFC/RFT PATCH v2 0/3] KVM: Introduce KVM_MEM_UNCACHED

On 14 May 2015 at 13:28, Paolo Bonzini pbonz...@redhat.com wrote: Well, PCI BARs are generally MMIO resources, and hence should not be cached. As an optimization, OS drivers can mark them as cacheable or write-combining or something like that, but in general it's a safe default to leave them

Re: [RFC/RFT PATCH v2 0/3] KVM: Introduce KVM_MEM_UNCACHED

On 14 May 2015 at 14:03, Andrew Jones drjo...@redhat.com wrote: On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote: On 14 May 2015 at 11:31, Andrew Jones drjo...@redhat.com wrote: Forgot to (4): switch from setting userspace's mapping to device memory to normal, non-cacheable

Re: [PATCH v4 03/12] KVM: arm64: guest debug, define API headers

On 15 May 2015 at 16:14, Alex Bennée alex.ben...@linaro.org wrote: Mark Rutland mark.rutl...@arm.com writes: On Fri, May 15, 2015 at 03:27:06PM +0100, Alex Bennée wrote: +/* + * See v8 ARM ARM D7.3: Debug Registers + * + * The control registers are architecturally defined as 32 bits but

Re: [RFC/RFT PATCH v2 0/3] KVM: Introduce KVM_MEM_UNCACHED

On 14 May 2015 at 11:31, Andrew Jones drjo...@redhat.com wrote: Forgot to (4): switch from setting userspace's mapping to device memory to normal, non-cacheable. Using device memory caused a problem that Alex Graf found, and Peter Maydell suggested using normal, non-cacheable instead. Did you

Re: [PATCH v4 10/12] KVM: arm64: guest debug, HW assisted debug support

On 15 May 2015 at 17:16, Alex Bennée alex.ben...@linaro.org wrote: Mark Rutland mark.rutl...@arm.com writes: This gets more fun when you consider the context-aware breakpoints are the highest numbered. So the set of (context-aware) breakpoints might not intersect across all CPUs. I didn't

Re: should KVM or userspace be the one which decides what MIPIDR/affinity values to assign to vcpus?

On 9 June 2015 at 11:52, Marc Zyngier marc.zyng...@arm.com wrote: On 08/06/15 11:52, Peter Maydell wrote: On 8 June 2015 at 11:32, Igor Mammedov imamm...@redhat.com wrote: On Thu, 4 Jun 2015 18:17:39 +0100 Peter Maydell peter.mayd...@linaro.org wrote: On 4 June 2015 at 17:40, Shlomo Pongratz

should KVM or userspace be the one which decides what MIPIDR/affinity values to assign to vcpus?

On 8 June 2015 at 11:32, Igor Mammedov imamm...@redhat.com wrote: On Thu, 4 Jun 2015 18:17:39 +0100 Peter Maydell peter.mayd...@linaro.org wrote: On 4 June 2015 at 17:40, Shlomo Pongratz shlomopongr...@gmail.com wrote: In order for it to work correctly we must use MPIDR values in the device

Re: [PATCH v5 2/6] target-arm: kvm64: introduce kvm_arm_init_debug()

--- Reviewed-by: Peter Maydell peter.mayd...@linaro.org thanks -- PMM ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v5 6/6] target-arm: kvm - re-inject guest debug exceptions

On 29 May 2015 at 16:19, Alex Bennée alex.ben...@linaro.org wrote: From: Alex Bennée a...@bennee.com If we can't find details for the debug exception in our debug state then we can assume the exception is due to debugging inside the guest. To inject the exception into the guest state we

Re: [PATCH v5 0/6] QEMU support for KVM Guest Debug on arm64

On 29 May 2015 at 16:19, Alex Bennée alex.ben...@linaro.org wrote: You may be wondering what happened to v3 and v4. They do exist but they didn't change much from the the original patches as I've been mostly looking the kernel side of the equation. So in summary the changes are: - updates

Re: should KVM or userspace be the one which decides what MIPIDR/affinity values to assign to vcpus?

On 9 June 2015 at 15:00, Marc Zyngier marc.zyng...@arm.com wrote: Yeah, what I had in mind was something along the lines of: - kernel computes its default MPDIR - kernel exposes a new capability KVM_ARM_ALLOW_MPIDR_OVERRIDE (or something along those lines) - userspace does the right thing.

Re: [PATCH] arm64/kvm: Add generic v8 KVM target

On 17 June 2015 at 10:00, Suzuki K. Poulose suzuki.poul...@arm.com wrote: From: Suzuki K. Poulose suzuki.poul...@arm.com This patch adds a generic ARM v8 KVM target cpu type for use by the new CPUs which eventualy ends up using the common sys_reg table. For backward compatibility the existing

Re: [PATCH] arm64/kvm: Add generic v8 KVM target

On 25 June 2015 at 14:44, Marc Zyngier marc.zyng...@arm.com wrote: It should always be possible to emulate a known CPU on a generic host, and it should be able to migrate. The case we can't migrate is when we let the guest be generic (which I guess should really be unknown, and not generic).

Re: should KVM or userspace be the one which decides what MIPIDR/affinity values to assign to vcpus?

On 25 June 2015 at 09:00, Christoffer Dall christoffer.d...@linaro.org wrote: Of course, KVM can deny an unsupported configuration, but I am wondering if we really think anybody will care about the 'model such specific hardware' aspect with KVM, or if we should only consider the 'I want a VM

Re: [PATCH v4 0/4] Add support for for GICv2m and MSIs to arm-virt

On 29 May 2015 at 12:01, Christoffer Dall christoffer.d...@linaro.org wrote: Now when we have a host generic PCIe controller in the virt board, it would be nice to be able to use MSIs so that we can eventually enable VHOST with KVM. With these patches you can use MSIs with TCG and with KVM,

Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

On 29 June 2015 at 18:20, Claudio Fontana claudio.font...@huawei.com wrote: On 26.06.2015 06:49, Jan Kiszka wrote: QEMU has the concept of write-back levels: KVM_PUT_RUNTIME_STATE, KVM_PUT_RESET_STATE and KVM_PUT_FULL_STATE. I suspect this registers is just sorted into the wrong category, thus

Re: [PATCH] arm64/kvm: Add generic v8 KVM target

On 29 June 2015 at 18:30, Marc Zyngier marc.zyng...@arm.com wrote: On 29/06/15 18:13, Chalamarla, Tirumalesh wrote: Will this also prevents migrating between same implementations, if no how is this identified. This shouldn't. It is pretty easy to look at the incoming guest's MIDR, and verify

Re: [PATCH] arm64: KVM: Enable minimalistic support for Thunder

On 29 June 2015 at 18:11, Marc Zyngier marc.zyng...@arm.com wrote: On 29/06/15 18:06, Chalamarla, Tirumalesh wrote: On Jun 29, 2015, at 1:53 AM, Marc Zyngier marc.zyng...@arm.com wrote: Constantly adding new CPUs without providing any insight as to how they should be emulated only brings

Re: [PATCH] arm64/kvm: Add generic v8 KVM target

On 3 July 2015 at 09:28, Marc Zyngier marc.zyng...@arm.com wrote: On 03/07/15 09:12, Peter Maydell wrote: I would still like to see the proponents of this patch say what their model is for userspace support of cross-host migration, if we're abandoning the model the current API envisages. I

Re: [PATCH 05/10] KVM: arm/arm64: vgic: Relax vgic_can_sample_irq for edge IRQs

On 3 July 2015 at 10:50, Marc Zyngier marc.zyng...@arm.com wrote: On 02/07/15 17:23, Christoffer Dall wrote: If we had a different *shared* device than the timer which is edge-triggered, don't we then also need to capture the physical distributor's pending state along with the state of the

Re: KVM Live migration with GICv3

On 12 August 2015 at 17:17, Marc Zyngier marc.zyng...@arm.com wrote: If you plan to do anything for GICv3, you should only deal with with the system register version of the CPU interface. Also, please make sure that you think about (and in terms of) the underlying state inside the GIC, which is

Re: [PATCH v2] target-arm: kvm: Differentiate registers based on write-back levels

On 22 July 2015 at 13:56, Claudio Fontana claudio.font...@huawei.com wrote: I can if you want check if this patch actually fixes the problem without the KVM workaround. Is this the version I am supposed to test, or should I wait for the next respin? Fixed version went into master earlier

Re: [PATCH v5 0/7] KVM: arm64: Implement API for vGICv3 live migration

test it, please note that this version is not > binary-compatible with previous one, the API has been seriously changed. > qemu patchess will be posted in some time. > > v4 => v5: > - Adapted to new API by Peter Maydell, Marc Zyngier and Christoffer Dall. > Acked-by's on the documenta

Re: [RFC PATCH v3 1/4] hw/intc/arm_gicv3_common: Add state information

On 24 October 2015 at 13:30, Shlomo Pongratz wrote: > Comment on the "workaround" see inline. > >> > +/* Workaround! >> > + * Linux (drivers/irqchip/irq-gic-v3.c) is enabling only group >> > one, >> > + * in gic_cpu_sys_reg_init it calls

Re: Virt MM DEBUG_LL support arm32

On 7 October 2015 at 01:32, Mario Smarduch wrote: > Hi Peter, >I noticed that icedcc, and 8250 don't work > with DEBUG_LL early debug print. And the kernel dies if > these are selected. Besides PL011 is there any other > serial devices that can be used for early debug

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 8 October 2015 at 10:10, Pavel Fedin wrote: > Sorry, didn't want to offend anyone. I just wanted to tell that i know > that you, as maintainers, have much more power than i do, and you can > always say "it's political decision, we just want it and that's final", > and if

Re: [PATCH] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 8 October 2015 at 13:45, Pavel Fedin wrote: >> Speaking of which, does the QEMU side of this patch set require first >> adding the GICv3 emulation for the data structures or is there a >> stand-alone migration patch set somewhere? > > I rolled it out a week ago: >

Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

On 8 July 2015 at 16:56, Marc Zyngier marc.zyng...@arm.com wrote: On 29/06/15 18:37, Peter Maydell wrote: On 29 June 2015 at 18:20, Claudio Fontana claudio.font...@huawei.com wrote: On 26.06.2015 06:49, Jan Kiszka wrote: QEMU has the concept of write-back levels: KVM_PUT_RUNTIME_STATE

Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

On 9 July 2015 at 15:17, Christoffer Dall christoffer.d...@linaro.org wrote: On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote: So I ran this through GDB, and this happens when the guest probes the virtio devices, specifically the backtrace tells me that

Re: [RFC PATCH] target-arm: kvm: Differentiate registers based on write-back levels

On 10 July 2015 at 12:00, Christoffer Dall christoffer.d...@linaro.org wrote: Some registers like the CNTVCT register should only be written to the kernel as part of machine initialization or on vmload operations, but never during runtime, as this can potentially make time go backwards or

Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

On 9 July 2015 at 11:22, Christoffer Dall christoffer.d...@linaro.org wrote: On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote: I suspect Jan is right and we really need to distinguish the KVM_PUT_*_STATE levels in ARM QEMU. This probably implies some kind of whitelist/override

Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org wrote: As I understand it, the problem is that if we ever run a VCPU after reading the value, and write back the value afterwards, you potentially make time go backwards and get inconsistent views of time from different

Re: [RFC PATCH] KVM: arm/arm64: Don't let userspace update CNTVOFF once guest is running

On 8 July 2015 at 17:37, Marc Zyngier marc.zyng...@arm.com wrote: On 08/07/15 17:06, Peter Maydell wrote: I'd prefer it if somebody could investigate to see why QEMU is actually doing this -- so far we just have speculation. I'd prefer that too, but so far people seem to be more comfortable

Re: [PATCH v2 2/5] KVM: arm64: Implement vGICv3 distributor and redistributor access from userspace

On 2 September 2015 at 09:09, Pavel Fedin wrote: > 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

Re: Building assigned device guest dt node from host device tree ...

On 1 September 2015 at 16:29, Eric Auger wrote: > - the device directory can be somewhere in /sys/devices/platform, ie. > can be in sub-directories. The first difficulty is to locate it. Do you > know any C routing doing find-file matching a file name pattern? Didn't > find

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 2 October 2015 at 11:18, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 02/10/2015 12:16, Peter Maydell wrote: >> On 2 October 2015 at 11:05, Paolo Bonzini <pbonz...@redhat.com> wrote: >>> On 02/10/2015 11:58, Peter Maydell wrote: >>>> I de

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 2 October 2015 at 11:05, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 02/10/2015 11:58, Peter Maydell wrote: >> I definitely dislike the latter -- userspace ends up having to >> emulate part of the CPU even though that CPU support is really >> there in hardware.

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 2 October 2015 at 10:30, Paolo Bonzini wrote: > > > On 02/10/2015 09:28, Pavel Fedin wrote: >> 2. Another possible approach, based on how device tree binding is handled >> by Linux. It is possible >> to remove virtual timer IRQ from the device tree, in this case the

Re: [RFC PATCH v5 0/3] vfio: platform: return device properties for a platform device

On 2 October 2015 at 21:28, Christoffer Dall wrote: > We discussed this for the purposes of ARM during SFO15 last week, and > basically arrived at the conclusion that the resonable thing to do is to > rely on sysfs device tree parsing in userspace. We don't have a

Re: [PATCH v3 5/5] KVM: arm64: Implement vGICv3 CPU interface access

On 25 September 2015 at 15:27, Andre Przywara wrote: > On 24/09/15 13:08, Pavel Fedin wrote: >> Hello! >> >>> The only thing that is pure 64-bit is the MRS/MSR _instruction_ in >>> Aarch64, which always takes a x register. >>> So can you model the register size according

Re: [PATCH v10 0/6] QEMU support for KVM Guest Debug on arm64

On 8 December 2015 at 18:32, Alex Bennée wrote: > Hi, > > Here is the latest patch set to support debugging of KVM guests on > arm64. The main changes are fixing arm32 compiles (mostly with stubs > for the upcomming arm32 debug) and the usual bunch of minor tweaks and >

Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device

On 8 January 2016 at 03:06, Shannon Zhao <zhaoshengl...@huawei.com> wrote: > > > On 2016/1/7 22:56, Peter Maydell wrote: >>>>> + Errors: >>>>> >>> +-ENXIO: Unsupported attribute group >>>>> >>> +-EBUSY: The

Re: [PATCH 1/2] arm: KVM: Do not update PC if the trap handler has updated it

On 22 December 2015 at 09:55, Marc Zyngier wrote: > Assuming we trap a coprocessor access, and decide that the access > is illegal, we will inject an exception in the guest. In this > case, we shouldn't increment the PC, or the vcpu will miss the > first instruction of the

Re: [PATCH 1/2] arm: KVM: Do not update PC if the trap handler has updated it

On 22 December 2015 at 14:39, Christoffer Dall <christoffer.d...@linaro.org> wrote: > On Tue, Dec 22, 2015 at 11:08:10AM +0000, Peter Maydell wrote: >> Won't this result in our incorrectly skipping the first insn >> in the fault handler if the original offending instruction &g

Re: [PATCH v9 1/6] target-arm: kvm64 - introduce kvm_arm_init_debug()

On 20 November 2015 at 15:05, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 12 November 2015 at 16:20, Alex Bennée <alex.ben...@linaro.org> wrote: >> As we haven't always had guest debug support we need to probe for it. >> Additionally we don't do this in the sta

Re: [PATCH v9 1/6] target-arm: kvm64 - introduce kvm_arm_init_debug()

{ > *features |= 1ULL << feature; > @@ -121,6 +137,8 @@ int kvm_arch_init_vcpu(CPUState *cs) > } > cpu->mp_affinity = mpidr & ARM64_AFFINITY_MASK; > > +kvm_arm_init_debug(cs); > + > return kvm_arm_init_cpreg_list(cpu); > }

Re: [PATCH v9 4/6] target-arm: kvm - add support for HW assisted debug

On 12 November 2015 at 16:20, Alex Bennée wrote: > This adds basic support for HW assisted debug. The ioctl interface to > KVM allows us to pass an implementation defined number of break and > watch point registers. When KVM_GUESTDBG_USE_HW is specified these > debug

Re: [PATCH v9 3/6] target-arm: kvm - support for single step

On 12 November 2015 at 16:20, Alex Bennée wrote: > This adds support for single-step. There isn't much to do on the QEMU > side as after we set-up the request for single step via the debug ioctl > it is all handled within the kernel. > > Signed-off-by: Alex Bennée

Re: [PATCH v9 6/6] tests/guest-debug: introduce basic gdbstub tests

On 12 November 2015 at 16:20, Alex Bennée wrote: > From: Alex Bennée > > The aim of these tests is to combine with an appropriate kernel > image (with symbol-file vmlinux) and check it behaves as it should. > Given a kernel it checks: > > - single step

Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device

On 11 January 2016 at 16:09, Andrew Jones wrote: > I think the save/restore case is where I always flip to seeing it as a > bunch of separate per cpu devices. It would feel better to me to > save/restore the cpu-gic registers the same way we do all other cpu > registers.

Re: [PATCH v8 20/20] KVM: ARM64: Add a new kvm ARM PMU device

On 11 January 2016 at 16:21, Andrew Jones wrote: > On Mon, Jan 11, 2016 at 05:09:27PM +0100, Andrew Jones wrote: >> On Mon, Jan 11, 2016 at 04:09:29PM +0100, Christoffer Dall wrote: >> > Are vcpu ids already exposed to userspace (beyond the stupid >> > KVM_IRQ_LINE) ioctl and

Re: ARM KVM guest virtual address to host virtual address Look up

On 15 January 2016 at 11:14, hiwu wrote: > I want to trap some ldr,str instruction in guest VM for debug. Therefore, I > have to emulate guest ldr,str in host. Without guest VA to host VA, I cannot > emulate ldr,str instruction in host. That sounds like you want "load/store

Re: ARM KVM guest virtual address to host virtual address Look up

On 15 January 2016 at 15:35, hiwu wrote: > Hi Peter: > > The guest's load/store instructions, which I want to debug, do not cause a > guest exception. > ARM KVM only provides the guest' r15 register (pc) value. To get the guest > instruction for > emulating in host,

Re: ARM KVM guest virtual address to host virtual address Look up

On 15 January 2016 at 09:33, wrote: > How to lookup host virtual address by guest virtual address ? > Is there any function to do guest page table walk? There is no single function to do this (depending on what bit of QEMU this is, we might either try a TLB access to see

Re: [Qemu-devel] [PATCH] virt: Lift the maximum RAM limit from 30GB to 255GB

[Typoed the kvmarm list address; sorry... -- PMM] On 25 February 2016 at 12:09, Peter Maydell <peter.mayd...@linaro.org> wrote: > The virt board restricts guests to only 30GB of RAM. This is a > hangover from the vexpress-a15 board, and there's inherent reason > for it. 30GB is s

Re: [Question] Can KVM run on Freescale IMX6 SABRE board?

On 25 February 2016 at 15:17, xu mike wrote: > I'm a student from the University of Pennsylvania. I want to try KVM on ARM > boards. > > I have a Freescale IMX6 board [1] which has ARM Cortex A9 processors. > I'm wondering if KVM can run on the Freescale IMX6 board? or > Can

Re: [PATCH v7 1/6] KVM: arm/arm64: Add VGICv3 save/restore API documentation

tributor, and CPU interface registers for GICv3 in this new file. > > Acked-by: Peter Maydell <peter.mayd...@linaro.org> > Acked-by: Marc Zyngier <marc.zyng...@arm.com> > Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org> > Signed-off-by: Pavel Fedin <p.fe

Re: [PATCH v9 21/21] KVM: ARM64: Add a new vcpu device control group for PMUv3

3_IRQ > attribute within the KVM_ARM_VCPU_PMU_V3_CTRL group. > > After configuring the PMUv3, call the vcpu iotcl with attribute > KVM_ARM_VCPU_PMU_V3_INIT to initialize the PMUv3. > > Signed-off-by: Shannon Zhao <shannon.z...@linaro.org> > --- > CC: Peter Maydell <peter.mayd.

Re: [PATCH v9 19/21] KVM: ARM64: Add a new feature bit for PMUv3

On 19 January 2016 at 07:10, Shannon Zhao wrote: > Yes, for checking the CAP true/false is enough. Maybe I think the number > of host counters could be useful for QEMU to know the number and for > supporting cross-type vcpu, but I'm not sure. If someone else has no >

Re: [PATCH v11 06/21] KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register

On 20 February 2016 at 13:15, Shannon Zhao wrote: > > > On 2016/2/8 20:09, Christoffer Dall wrote: >> Isn't it really a BUG_ON(p->is_write) ? >> >> Presumably a guest write to these registers will raise an undefined >> exception in EL0/1 and we don't get here by any other

Re: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

On 14 March 2016 at 11:13, Andre Przywara wrote: > So I see two ways to fix this: > 1.) we find a KVM specific way of letting userland save and restore the > ITS tables directly > 2.) we implement the BASER registers, but still use our "cache" for > normal operations. On

Re: [PATCH v3 00/16] KVM: arm64: GICv3 ITS emulation

On 18 March 2016 at 09:40, Christoffer Dall wrote: > On Mon, Mar 14, 2016 at 06:20:36PM +, Andre Przywara wrote: >> Well, probably there is not so much difference. I was just wondering if >> it would be easier to treat that data as an opaque blob. >> But you are

Re: [PATCH v7 1/6] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 21 April 2016 at 19:30, Christoffer Dall wrote: > So I agree about the latch state, that should be exported, if nothing > else so that a VM can't use this particular change to detect a > migration, for example. > > However, for the input level, I really do see this

Re: Re: [Query] Does Linux & Qemu support KVM for ARM32 guest on ARM64 host

On 28 April 2016 at 07:03, RAVINDRA KUMAR SANDE wrote: > I have another query, for Arm32 host with KVM enabled. > I see that "qemu-system-arm -enable-kvm -machine vexpress-a9 ..." gives > error > kmv_init_vcpu (IOCtl on /dev/kvm) failed, guest not supported. > > Is there

Re: [PATCH v5 1/2] arm/arm64: KVM: Detect vGIC presence at runtime

On 21 April 2016 at 22:41, Alexander Graf wrote: > So effectively all we'd need is to set CNTHCTL_EL2.EL1PCEN to 0 for > guests that have no in-kernel irqchip, no? We should then trap on all > timer accesses and be able to emulate them in user space where we can > inject IRQs into

Re: [PATCH v5 1/2] arm/arm64: KVM: Detect vGIC presence at runtime

On 21 April 2016 at 23:35, Alexander Graf wrote: > It might make sense to have a generic "system register couldn't get > handled" exit code anyway. If nothing else, at least to display > unhandled registers in the qemu context where they appear rather than in > the kernel log

Re: [PATCH v3] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 18 May 2016 at 18:03, Christoffer Dall <christoffer.d...@linaro.org> wrote: > On Fri, May 13, 2016 at 04:28:44PM +0100, Peter Maydell wrote: >> I would like this to simply get/set the latch state regardless of whether >> the interrupt is edge triggered or level

Re: [PATCH v3] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 13 May 2016 at 15:43, Christoffer Dall wrote: > Factor out the GICv3-specific documentation into a separate > documentation file. Add description for how to access distributor, > redistributor, and CPU interface registers for GICv3 in this new file, > and add a

Re: [PATCH v3 27/55] KVM: arm/arm64: vgic-new: Add PRIORITY registers handlers

On 12 May 2016 at 10:10, Marc Zyngier wrote: > This is wrong. We should only write the number of bits of priority we > actually emulate. And given that we use a common framework for v2 and > v3, this should probably be 5 bits (32 priorities should be enough for > everybody).

Re: [PATCH v3 19/55] KVM: arm/arm64: vgic-new: Add GICv3 world switch backend

On 10 May 2016 at 15:04, Christoffer Dall wrote: > On Fri, May 06, 2016 at 11:45:32AM +0100, Andre Przywara wrote: >> + /* >> + * Currently all guest IRQs are Group1, as Group0 would result >> + * in a FIQ in the guest, which it wouldn't expect. > > I

Re: [PATCH v7 1/6] KVM: arm/arm64: Add VGICv3 save/restore API documentation

tributor, and CPU interface registers for GICv3 in this new file. > > Acked-by: Peter Maydell <peter.mayd...@linaro.org> > Acked-by: Marc Zyngier <marc.zyng...@arm.com> > Signed-off-by: Christoffer Dall <christoffer.d...@linaro.org> > Signed-off-by: Pavel Fedin

Re: [PATCH v7 1/6] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 15 April 2016 at 14:58, Peter Maydell <peter.mayd...@linaro.org> wrote: > Nothing in here describes a mechanism for reading or writing the > current interrupt line_level state from the kernel (which doesn't > matter for edge triggered interrupts but does for level triggered >

Re: [PATCH v7 1/6] KVM: arm/arm64: Add VGICv3 save/restore API documentation

On 20 April 2016 at 11:59, Christoffer Dall <christoffer.d...@linaro.org> wrote: > On Friday, 15 April 2016, Peter Maydell <peter.mayd...@linaro.org> wrote: >> Nothing in here describes a mechanism for reading or writing the >> current interrupt line_level state fro

Re: [PATCH 24/45] KVM: arm/arm64: vgic-new: Add GICv3 CTLR, IIDR, TYPER handlers

On 15 April 2016 at 18:11, Andre Przywara wrote: > As in the GICv2 emulation we handle those three registers in one > function. > > Signed-off-by: Andre Przywara > > Changelog RFC..v1: > - kick VCPUs if distributor gets enabled > --- >

Re: [PATCH v5] KVM: arm/arm64: Add VGICv3 save/restore API documentation

parameter in > + kvm_device_attr.addr. > + Errors: > +-ENXIO: ITS not properly configured as required prior to calling > + this attribute "setting this attribute". > +-ENOMEM: Memory shortage when allocating ITS internal data Otherwise Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> -- PMM ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [RFC PATCH v2 0/4] arm/arm64: vgic-new: Implement API for vGICv3 live migration

On 11 August 2016 at 06:29, Vijay Kilari <vijay.kil...@gmail.com> wrote: > On Tue, Aug 9, 2016 at 5:22 PM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> On 9 August 2016 at 11:58, <vijay.kil...@gmail.com> wrote: >>> From: Vijaya Kumar K <vijaya.ku

Re: issues with emulated PCI MMIO backed by host memory under KVM

On 27 June 2016 at 10:47, Ard Biesheuvel wrote: > As for the USB case, I can't really figure out what is going on here, > but I am fairly certain it is a different issue. If this is related to > DMA, I wonder if adding the 'dma-coherent' property to the PCIe root >

Re: issues with emulated PCI MMIO backed by host memory under KVM

On 27 June 2016 at 14:49, Mark Rutland <mark.rutl...@arm.com> wrote: > On Mon, Jun 27, 2016 at 02:15:29PM +0100, Peter Maydell wrote: >> I get the impression dma-coherent is the right thing to advertise >> anyway. Do you have the documentation to hand that specifies what &g

Re: [PATCH v7 10/17] KVM: arm64: introduce new KVM ITS device

On 5 July 2016 at 09:59, Andre Przywara wrote: > Ah, OK, so you _do_ the address setup _after_ the INIT. > My understanding of the KVM API was that this isn't allowed, as with the > INIT _everything_ should have been setup. kvmtool works this way. > > So we obviously can't

Re: [RESEND PATCH v4] KVM: arm/arm64: Add VGICv3 save/restore API documentation

e. > + > +PPIs are reported per VCPU as specified in the mpidr field, and SPIs are > +reported with the same value regardless of the mpidr specified. > + > +The mpidr field encodes the CPU ID based on the affinity information in > the > +architecture defined MPI

  1   2   3   >