On 7 January 2016 at 14:49, Shannon Zhao wrote:
>
>
> On 2016/1/7 22:36, Peter Maydell wrote:
>> On 22 December 2015 at 08:08, Shannon Zhao wrote:
>>> From: Shannon Zhao
>>>
>>> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PM
On 22 December 2015 at 08:08, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new kvm device type KVM_DEV_TYPE_ARM_PMU_V3 for ARM PMU. Implement
> the kvm_device_ops for it.
>
> Signed-off-by: Shannon Zhao
> ---
> Documentation/virtual/kvm/devices/arm-pmu.txt | 24 +
> arch/arm64/includ
On 22 December 2015 at 14:39, Christoffer Dall
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
>> was itself the first
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 handler, leading to a mi
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
> clarifications following re
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
> - software breakpoint
> - hardware b
On 12 November 2015 at 16:20, Alex Bennée wrote:
> From: Alex Bennée
>
> 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-use the TCG exception
> code (
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 registers will be installed in
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
>
> ---
> v2
> - convert to us
On 12 November 2015 at 16:20, Alex Bennée wrote:
> These don't involve messing around with debug registers, just setting
> the breakpoint instruction in memory. GDB will not use this mechanism if
> it can't access the memory to write the breakpoint.
>
> All the kernel has to do is ensure the hyper
On 20 November 2015 at 15:05, Peter Maydell wrote:
> On 12 November 2015 at 16:20, Alex Bennée wrote:
>> As we haven't always had guest debug support we need to probe for it.
>> Additionally we don't do this in the start-up capability code so we
>> don't fa
gt; @@ -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);
> }
I assume in practice the kernel guarantees that either all
CPUs
On 10 November 2015 at 16:59, Andrew Jones wrote:
> On Tue, Nov 10, 2015 at 04:29:31PM +0000, Peter Maydell wrote:
>> On 10 November 2015 at 00:23, Andrew Jones wrote:
>> > -/* KVM uses PAGE_SIZE in its definition of COALESCED_MMIO_MAX */
>> > -#define PAGE_SIZE TA
On 10 November 2015 at 00:23, Andrew Jones wrote:
> Just noticed this while grepping TARGET_PAGE_SIZE for an unrelated
> reason. I didn't use qemu_real_host_page_size as kvm_set_phys_mem()
> does, because we'd need to make sure page_size_init() has run first.
>
> Signed-off-by: Andrew Jones
> ---
On 5 November 2015 at 06:50, Pavel Fedin
> You know, since we are talking about this... This definitely
> has something to do with the reset, and... Looks like nobody
> resets vGIC/vTimer, unless the userland does it explicitly by
> resetting every register by hand.
This is how KVM in-kernel de
On 26 October 2015 at 10:12, Denis V. Lunev wrote:
> On 10/26/2015 01:03 PM, Peter Maydell wrote:
>> Hi. Changes to linux-headers/ should only be made as part of
>> an automated update from a mainline Linux kernel tree using
>> the scripts/update-linux-headers.sh script. Thi
On 26 October 2015 at 09:50, Andrey Smetanin wrote:
> Signed-off-by: Andrey Smetanin
> Reviewed-by: Roman Kagan
> Signed-off-by: Denis V. Lunev
> CC: Vitaly Kuznetsov
> CC: "K. Y. Srinivasan"
> CC: Gleb Natapov
> CC: Paolo Bonzini
> CC: Roman Kagan
> CC: Denis V. Lunev
> CC: kvm@vger.kern
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 documentation were dropped, just in
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:
> https://www.mail-archive.co
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 you choose to do this,
On 5 October 2015 at 08:18, Michael Tokarev wrote:
> 05.10.2015 08:18, Markus Armbruster wrote:
>> Why? I like having the semantic patch in the commit message when
>> there's any chance we'll want do the same mechanical change again later.
>>
>> You could save space and include it by reference, t
On 2 October 2015 at 11:18, Paolo Bonzini wrote:
>
>
> On 02/10/2015 12:16, Peter Maydell wrote:
>> On 2 October 2015 at 11:05, Paolo Bonzini wrote:
>>> On 02/10/2015 11:58, Peter Maydell wrote:
>>>> I definitely dislike the latter -- userspace ends up having
On 2 October 2015 at 11:05, Paolo Bonzini 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. Also it requires us to
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 kernel
>> reverts to usin
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 to the spec and allow
>>>
On 25 September 2015 at 01:37, Shraddha Barke wrote:
> Compress lines and remove the variable ret.
>
> Change made using Coccinelle script
> diff --git a/hw/timer/tusb6010.c b/hw/timer/tusb6010.c
> index 459c748..ba01050 100644
> --- a/hw/timer/tusb6010.c
> +++ b/hw/timer/tusb6010.c
> @@ -321,7 +
On 15 September 2015 at 17:15, Will Deacon wrote:
> Although the ThumbEE registers and traps were present in earlier
> versions of the v8 architecture, it was retrospectively removed and so
> we can do the same.
>
> Cc: Marc Zyngier
> Signed-off-by: Will Deacon
> diff --git a/arch/arm64/kvm/sys
On 4 September 2015 at 15:05, Andrew Jones wrote:
> But anyway I would suggest you do your 'make clean' or even a
> 'make distclean' *before* running configure the second time.
> Otherwise you'll leave old object files around from the previously
> configured arch. I.e. you want 'make clean' to app
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 specification.
> KVM_D
On 1 September 2015 at 14:52, Andre Przywara wrote:
> Also the GIC specification says that everything must be accessible with
> 32-bit accesses. Correct me if I am wrong on this, but vCPUs are not
> supposed to run while you are getting/setting VGIC registers, right? So
> there shouldn't be any is
On 30 August 2015 at 17:50, Christoffer Dall
wrote:
> I had imagined we would encode the GICv3 register accesses through the
> device API and not through the system register API, since I'm not crazy
> about polluting the general system register handling logic with GIC
> registers solely for the pu
On 9 July 2015 at 15:17, Christoffer Dall 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
>
> virtio_current_cpu_endian () at /root/src/qemu
On 9 July 2015 at 14:58, Peter Maydell wrote:
> On 9 July 2015 at 14:49, Paolo Bonzini wrote:
>> It's the same---they can go in through any tree. In this case I've now
>> applied them and will send them out next week.
>
> I've actually just applied them t
On 9 July 2015 at 12:52, Leon Alrae wrote:
> On 09/07/2015 10:17, James Hogan wrote:
>> These two patches fix build errors for the MIPS TCG backend and MIPS
>> KVM.
>>
>> Please could they be applied for v2.4.
>>
>> James Hogan (2):
>> tcg/mips: Fix build error from merged memop+mmu_idx paramete
On 9 July 2015 at 14:49, Paolo Bonzini wrote:
>
>
> On 09/07/2015 10:13, Leon Alrae wrote:
>> On 08/07/2015 16:22, Paolo Bonzini wrote:
>>> On 08/07/2015 17:03, James Hogan wrote:
Hi Paolo,
On 24/04/15 11:26, James Hogan wrote:
> A couple of small fixes for accessing 32-bit KVM
On 9 July 2015 at 13:05, Christoffer Dall 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
> VCPUs because they may have
On 9 July 2015 at 11:22, Christoffer Dall 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 m
On 8 July 2015 at 17:37, Marc Zyngier 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
On 8 July 2015 at 16:56, Marc Zyngier wrote:
> On 29/06/15 18:37, Peter Maydell wrote:
>> On 29 June 2015 at 18:20, Claudio Fontana wrote:
>>> On 26.06.2015 06:49, Jan Kiszka wrote:
>>>> QEMU has the concept of write-back levels: KVM_PUT_RUNTIME_STATE
On 3 July 2015 at 10:50, Marc Zyngier 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 device unless we
On 3 July 2015 at 09:28, Marc Zyngier 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 e
On 3 July 2015 at 09:08, Marc Zyngier wrote:
> On 02/07/15 21:29, Chalamarla, Tirumalesh wrote:
>> is there a chance that this get merged in to 4.2? if not is it possible
>> to accept the other patches like adding implementations explicitly(like
>> Thunder).
>
> We first need to reach a conclusion
On 29 June 2015 at 18:30, Marc Zyngier 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 that it matc
On 29 June 2015 at 18:20, Claudio Fontana 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 written as part of
On 25 June 2015 at 14:44, Marc Zyngier 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).
>
> So if the us
On 25 June 2015 at 09:59, Claudio Fontana wrote:
> Once the VM is created, I think QEMU should not request kvm to
> change the virtual offset of the VM anymore: maybe an unexpected
> consequence of QEMU's target-arm/kvm64.c::kvm_arch_put_registers ?
Hmm. In general we assume that we can:
* stop
On 23 June 2015 at 15:03, Suzuki K. Poulose wrote:
> On 23/06/15 13:39, Christoffer Dall wrote:
>> On Mon, Jun 22, 2015 at 09:44:48AM +0100, Peter Maydell wrote:
>> I'm guessing the intention is to avoid having to add code in the kernel
>> to support KVM on a new CPU w
On 17 June 2015 at 10:00, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> 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 targets have been
> preserved. Any ne
On 17 June 2015 at 12:53, Eric Auger wrote:
> shouldn't we test somewhere that the hwirq is between 16 and 1019.
Not directly related, but that reminds me that I noticed the
other day that we have VGIC_MAX_IRQS = 1024 (and use that as a
guard on how many irqs we let userspace configure and ask us
On 29 May 2015 at 16:19, Alex Bennée 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 to the kernel ABI
On 29 May 2015 at 16:19, Alex Bennée wrote:
> From: Alex Bennée
>
> 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-use the TCG exception
> code (do_in
On 29 May 2015 at 16:19, 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_BP is specified these
> debug registers will be installed in p
On 29 May 2015 at 16:19, 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
>
> ---
> v2
> - convert to using H
On 29 May 2015 at 16:19, Alex Bennée wrote:
> These don't involve messing around with debug registers, just setting
> the breakpoint instruction in memory. GDB will not use this mechanism if
> it can't access the memory to write the breakpoint.
>
> All the kernel has to do is ensure the hypervisor
On 29 May 2015 at 16:19, Alex Bennée wrote:
> As we haven't always had guest debug support we need to probe for it.
> Additionally we don't do this in the start-up capability code so we
> don't fall over on old kernels.
>
> Signed-off-by: Alex Bennée
> ---
Re
On 27 May 2015 at 10:30, Paolo Bonzini wrote:
> For example, ARM's "-M virt" uses a pl011 block for the RTC, and also
> uses fw_cfg. Another commonly used ISA device is the UART, for which
> again -M virt uses a pl031.
Partly we do that because there were a number of reports that trying
to use v
On 22 May 2015 at 12:12, Daniel P. Berrange wrote:
> Yep, it is hard saying no - but I'd think as long as it was possible to add
> the extra features using -device, it ought to be practical to keep a "virt"
> machine types "-nodefaults -nodefconfig" base setup pretty minimal.
Mmm, but -device onl
On 22 May 2015 at 12:01, Daniel P. Berrange wrote:
> On the QEMU side of things I wonder if there is scope for taking AArch64's
> 'virt' machine type concept and duplicating it on all architectures.
Experience suggests that holding the line on "minimal" is really
quite tricky, though -- there's a
On 15 May 2015 at 16:14, Alex Bennée wrote:
>
> Mark Rutland 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 are
>>> + * stored as 64 bit
On 28 April 2015 at 09:42, Alex Bennée wrote:
> Peter Maydell writes:
>> Does the kernel already have a conveniently implemented "inject
>> exception into guest" lump of code? If so it might be less effort
>> to do it that way round, maybe.
>
> So you po
On 27 April 2015 at 21:04, Christoffer Dall wrote:
> On Thu, Apr 23, 2015 at 03:26:53PM +0100, Alex Bennée wrote:
>>
>> Christoffer Dall writes:
>>
>> > On Tue, Mar 31, 2015 at 04:08:04PM +0100, Alex Bennée wrote:
>> >> + * just need to report the PC and the HSR values to userspace.
>> >> + * Use
On 21 April 2015 at 13:56, Alex Bennée wrote:
>
> Peter Maydell writes:
>>> switch (hsr_ec) {
>>> +case HSR_EC_SOFT_STEP:
>>> +if (cs->singlestep_enabled) {
>>> +return true;
>>> +} else {
>>&
On 31 March 2015 at 16:40, Alex Bennée wrote:
> From: Alex Bennée
>
> 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 is specified these
> debug registe
On 31 March 2015 at 16:40, 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
>
> ---
> v2
> - convert to using
On 31 March 2015 at 16:40, Alex Bennée wrote:
> These don't involve messing around with debug registers, just setting
> the breakpoint instruction in memory. GDB will not use this mechanism if
> it can't access the memory to write the breakpoint.
>
> All the kernel has to do is ensure the hypervis
On 8 April 2015 at 13:28, Paolo Bonzini wrote:
> Let kvm_arch_post_run convert fields in the kvm_run struct to MemTxAttrs.
> These are then passed to address_space_rw.
>
> Signed-off-by: Paolo Bonzini
Reviewed-by: Peter Maydell
At some point it might be nice to support r
On 1 April 2015 at 16:39, Alex Bennée wrote:
> --- a/target-arm/kvm.c
> +++ b/target-arm/kvm.c
> @@ -28,6 +28,8 @@ const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
> KVM_CAP_LAST_INFO
> };
>
> +static bool cap_has_mp_state = false;
This explicit init to false is unnecessary, and
On 1 April 2015 at 17:01, Alex Bennée wrote:
>
> David Hildenbrand writes:
>>> +/*
>>> + * See ARM ARM D7.3: Debug Registers
>>
>> Maybe drop one ARM
>
> Well technically it is the ARM Architecture Reference Manual but that's
> quite long winded.
Dropping one "ARM" would be actively wrong, so d
On 23 March 2015 at 17:05, Alex Bennée wrote:
> I was getting very confused about the duplication of state so wanted to
> make it explicit.
>
> Signed-off-by: Alex Bennée
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 083211c..6dc1799 100644
> --- a/target-arm/cpu.h
> +++ b/target-a
On 23 March 2015 at 17:05, Alex Bennée wrote:
> The current code was negatively indexing the cpu state array and not
> synchronizing banked spsr register state with the current mode's spsr
> state, causing occasional failures with migration.
>
> Some munging is done to take care of the aarch64 map
On 23 March 2015 at 17:05, Alex Bennée wrote:
> +/* Advanced SIMD and FP registers
> + * We map Qn = regs[2n+1]:regs[2n]
> + */
> +for (i = 0; i < 32; i++) {
> +int rd = i << 1;
> +float128 fp_val = make_float128(env->vfp.regs[rd + 1],
> +
On 23 March 2015 at 17:05, Alex Bennée wrote:
> As there is logic to deal with the difference between edge and level
> triggered interrupts in the kernel we must ensure it knows the
> configuration of the IRQs before we restore the pending state.
>
> Signed-off-by: Alex Bennée
> Acked-by: Christo
On 23 March 2015 at 17:05, Alex Bennée 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 not. We then save t
On 24 March 2015 at 14:32, Greg Bellows wrote:
> On Mon, Mar 23, 2015 at 12:05 PM, Alex Bennée wrote:
>> From: Peter Maydell
>> @@ -523,7 +523,7 @@ void aarch64_cpu_do_interrupt(CPUState *cs)
>> aarch64_save_sp(env, arm_current_el(env));
>> en
On 17 March 2015 at 19:04, Christoffer Dall wrote:
> On Tue, Mar 17, 2015 at 04:18:16PM +0000, 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.
>
> righ
On 16 March 2015 at 11:01, Alex Bennée wrote:
> From: Christoffer Dall
>
> The current code was negatively indexing the cpu state array and not
> synchronizing banked spsr register state with the current mode's spsr
> state, causing occasional failures with migration.
>
> Some munging is done to
On 16 March 2015 at 11:01, Alex Bennée wrote:
> I was getting very confused about the duplication of state so wanted to
> make it explicit.
>
> Signed-off-by: Alex Bennée
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 083211c..6dc1799 100644
> --- a/target-arm/cpu.h
> +++ b/target-a
On 16 March 2015 at 11:01, Alex Bennée 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
>
> ---
>
> v4:
> - fixed merge con
On 16 March 2015 at 11:01, Alex Bennée 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 not. We then save t
On 12 March 2015 at 15:51, Peter Maydell wrote:
> On 4 March 2015 at 14:35, Alex Bennée 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
On 4 March 2015 at 14:35, Alex Bennée 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 papering over other
On 4 March 2015 at 14:35, Alex Bennée 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 not. We then save th
On 25 February 2015 at 16:02, Alex Bennée 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 questions about future di
On 10 March 2015 at 04:29, Christoffer Dall wrote:
> On Mon, Mar 09, 2015 at 04:34:21PM +, Alex Bennée wrote:
>> - Boot
>> - Power on secondary CPUs
>> - Power off one secondary CPU
>> - Migrate to file (cpu_powered reflects state of each CPU)
>>
>> - Start fresh QEMU
>> - Restore from file (c
On 9 March 2015 at 21:56, Christoffer Dall wrote:
> this function, however, is not used only when migration, but should
> generally cover the case where you want to synchronize QEMU's state into
> KVM's state, right? So while it may not be harmful in currently
> supported use cases, is there ever
On 5 March 2015 at 20:04, Catalin Marinas 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:
>> >
>> > http://threa
On 4 March 2015 at 23:35, Alex Bennée 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?
Doesn't seem worth changing the current working code to something
else that's strictly less effic
On 4 March 2015 at 23:29, Catalin Marinas wrote:
> I disagree it is 100% a host-side issue. It is a host-side issue _if_
> the host tells the guest that the (virtual) device is non-coherent (or,
> more precisely, it does not explicitly tell the guest that the device is
> coherent). If the guest th
On 3 March 2015 at 20:06, Paolo Bonzini wrote:
>
>
> On 03/03/2015 11:56, Alex Bennée 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 f
On 26 February 2015 at 01:02, Alex Bennée 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 not.
By this yo
On 16 February 2015 at 06:56, Jan Kiszka wrote:
> This applies to both emulated and KVM accelerated mode. If I run the
> same image (and guest kernel) emulated on my x86 box, there is still a
> difference between both disk modes, but it's not that excessive. On ARM
> the system requires minutes to
On 6 February 2015 at 18:55, Will Deacon wrote:
> On Wed, Feb 04, 2015 at 03:39:50PM +, Andre Przywara wrote:
>> In PCI config space there is an interrupt line field (offset 0x3f),
>> which is used to initially communicate the IRQ line number from
>> firmware to the OS. _Hardware_ should never
On 13 January 2015 at 13:35, Christoffer Dall
wrote:
> Wouldn't a guest (and I believe Linux does this) reserve ASID 0 for
> additional cores and use ASID 1+++ for itself?
If the guest reserves an ASID for "MMU disabled" then yes, that would
work. The question of course is whether all guests do t
On 13 January 2015 at 12:04, Christoffer Dall
wrote:
> Additionally, I haven't been able to think of a reasonable guest
> scenario where this breaks. Once the guest turns on its MMU it should
> deal with the necessary icache invalidation itself (I think), so we're
> really talking about situation
On 11 January 2015 at 17:58, Christoffer Dall
wrote:
> On Sun, Jan 11, 2015 at 05:37:52PM +0000, Peter Maydell wrote:
>> On 11 January 2015 at 12:33, Christoffer Dall
>> wrote:
>> > On Fri, Jan 09, 2015 at 03:28:58PM +, Peter Maydell wrote:
>> >> But imple
On 11 January 2015 at 12:33, Christoffer Dall
wrote:
> On Fri, Jan 09, 2015 at 03:28:58PM +0000, Peter Maydell wrote:
>> But implementations are allowed to hit in the cache even
>> when the cache is disabled. In particular, setting the guest
>
> But how can it hit anything wh
On 9 January 2015 at 14:16, Marc Zyngier wrote:
> On 09/01/15 13:03, Peter Maydell wrote:
>> When we reset a cpu by re-calling KVM_ARM_VCPU_INIT, that doesn't
>> mean we get a new VMID for it, though, does it? I thought that
>> what causes the icache flush to happen for
On 9 January 2015 at 12:50, Christoffer Dall
wrote:
> On Thu, Jan 08, 2015 at 03:21:50PM +0000, Peter Maydell wrote:
>> If this is the first instruction in the guest (ie we've just
>> (warm) reset the VM and are running the kernel as loaded into the guest
>> by QEMU/kvm
On 8 January 2015 at 15:06, Marc Zyngier wrote:
> On 08/01/15 13:16, Peter Maydell wrote:
>>> ASID cached VIVT icaches are also VMID tagged. It is thus impossible for
>>> stale cache lines to come with a new page. And if by synchronizing the
>>> caches you obtain
On 8 January 2015 at 13:07, Marc Zyngier wrote:
>> Can you remind me why it's OK not to flush the icache for an
>> ASID tagged VIVT icache? Making this page coherent might actually
>> be revealing a change in the instructions associated with the VA,
>> mightn't it?
>
> ASID cached VIVT icaches are
1 - 100 of 540 matches
Mail list logo
