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 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:
> 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 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 27 April 2015 at 14:41, Alexander Graf wrote:
> Peter, would you have a hard time if we just get rid of VIRT_MMIO completely
> and allow users to create the mmio-virtio bridges using -device for -M
> virt-2.4 and above?
I would strongly prefer not -- it breaks existing working command
lines. I
On 27 April 2015 at 18:04, Alexander Graf wrote:
> On 04/27/2015 06:58 PM, Christopher Covington wrote:
>> I'm not sure I have an opinion one way or the other, but I would like to
>> understand the "big waste" argument. Is there something that users are
>> eager
>> to reuse this address space for,
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 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 29 April 2015 at 10:03, Alexander Graf wrote:
>
>
> On 18.03.15 20:10, Andrew Jones wrote:
>> Introduce a new memory region flag, KVM_MEM_UNCACHED, which
>> is needed by ARM. This flag informs KVM that the given memory
>> region is typically mapped by the guest as uncached. KVM for
>> ARM then
On 27 April 2015 at 18:31, Christoffer Dall 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, but you still
> need s
On 6 May 2015 at 17:33, Peter Maydell wrote:
> On 27 April 2015 at 18:31, Christoffer Dall
> 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.
>
On 14 May 2015 at 11:31, Andrew Jones 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.
D
On 14 May 2015 at 13:28, Paolo Bonzini 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 uncached---one
On 14 May 2015 at 14:03, Andrew Jones wrote:
> On Thu, May 14, 2015 at 11:37:46AM +0100, Peter Maydell wrote:
>> On 14 May 2015 at 11:31, Andrew Jones wrote:
>> > Forgot to (4): switch from setting userspace's mapping to
>> > device memory to normal, no
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 15 May 2015 at 17:16, Alex Bennée wrote:
> Mark Rutland 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 see a reference to that in the ARM A
On 25 May 2015 at 14:09, Pavel Fedin wrote:
> Hello!
>
>> typedef struct MemMapEntry {
>> @@ -88,6 +90,7 @@ typedef struct VirtBoardInfo {
>> int fdt_size;
>> uint32_t clock_phandle;
>> uint32_t gic_phandle;
>> +uint32_t v2m_phandle;
>> } VirtBoardInfo;
>
> Could you rename
On 26 May 2015 at 13:54, Eric Auger wrote:
> Reviewed-by: Eric Auger
>
> The only question I have is related to mid-term virt strategy about
> GICv3 integration. Are we going to reuse that memory map for the machine
> instantiating the GICv3? If yes, shouldn't we put the GICv2M somewhere
> else t
On 26 May 2015 at 14:07, Eric Auger wrote:
> On 05/26/2015 02:55 PM, Peter Maydell wrote:
>> On 26 May 2015 at 13:54, Eric Auger wrote:
>>> Reviewed-by: Eric Auger
>>>
>>> The only question I have is related to mid-term virt strategy about
>>>
On 29 May 2015 at 12:01, Christoffer Dall 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, but you still
> need som
On 10 April 2015 at 09:15, Paolo Bonzini wrote:
>
>
> On 10/04/2015 09:48, Eric Auger wrote:
>> After the introduction of gicv2m, this series adds missing pieces to
>> run VIRTIO-PCI with vhost back-end on ARM.
>>
>> It is proposed to use the kvm_gsi_direct_mapping modality that sets
>> the irqfd
On 2 June 2015 at 12:29, Eric Auger wrote:
> This series enables machvirt to dynamically instantiate sysbus
> devices from command line (using -device option).
>
> All those sysbus devices are plugged onto a platform bus. This latter
> device is instantiated in machvirt and takes care of the bindi
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 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:
> 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:
> 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:
> 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 8 June 2015 at 11:32, Igor Mammedov wrote:
> On Thu, 4 Jun 2015 18:17:39 +0100
> Peter Maydell wrote:
>> On 4 June 2015 at 17:40, Shlomo Pongratz wrote:
>> In order for it to work correctly we must use MPIDR values in
>> the device tree which match the MPIDR valu
On 9 June 2015 at 11:52, Marc Zyngier wrote:
> On 08/06/15 11:52, Peter Maydell wrote:
>> On 8 June 2015 at 11:32, Igor Mammedov wrote:
>>> On Thu, 4 Jun 2015 18:17:39 +0100
>>> Peter Maydell wrote:
>>>> On 4 June 2015 at 17:40, Shlomo Pongratz wrote:
>
On 9 June 2015 at 13:27, Marc Zyngier wrote:
> On 09/06/15 12:24, Peter Maydell wrote:
>> So either:
>> * QEMU needs to tell the kernel the MPIDR for each vCPU
>> * QEMU needs to ask the kernel the MPIDR for each vCPU
>>
>> Which is better? The latter is simpl
On 9 June 2015 at 15:00, Marc Zyngier 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.
You forgot
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 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 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 25 June 2015 at 09:00, Christoffer Dall 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 with x VCPUs' scenario, i
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 25 June 2015 at 13:41, Christoffer Dall wrote:
> On Thu, Jun 25, 2015 at 10:06:20AM +0100, Peter Maydell wrote:
>> I agree it's not very likely anybody cares about the specific cluster
>> topology. However if we don't want to support arbitrary topologies
>> then
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 29 June 2015 at 18:11, Marc Zyngier wrote:
> On 29/06/15 18:06, Chalamarla, Tirumalesh wrote:
>>
>>> On Jun 29, 2015, at 1:53 AM, Marc Zyngier wrote:
>>> Constantly adding new CPUs without providing any insight as to how they
>>> should be emulated only brings churn, and not much benefit.
>>>
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 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 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 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 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 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 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 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 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 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 10 July 2015 at 12:00, Christoffer Dall 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
> create inconsistent time obs
On 11 July 2015 at 13:18, Christoffer Dall wrote:
> On Fri, Jul 10, 2015 at 12:22:31PM +0100, Peter Maydell wrote:
>> On 10 July 2015 at 12:00, Christoffer Dall
>> wrote:
>> > +/* All system registers not listed in the following table are assumed to
>&
On 16 July 2015 at 12:34, Christoffer Dall 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
> create inconsistent time obs
On 22 July 2015 at 13:56, Claudio Fontana 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 this week, so test that
On 12 August 2015 at 17:17, Marc Zyngier 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 closely
related to
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 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 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 any in qemu, nor in gli
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 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 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 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 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 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 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 great
> solution for ACPI yet, b
On 5 October 2015 at 10:37, Christoffer Dall
wrote:
> On Fri, Oct 02, 2015 at 11:53:07PM +0100, Peter Maydell wrote:
>> * I don't really want to build in a lot of infrastructure into
>>QEMU to either build the DTC compiler into it or else introduce
>>a run
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 with Virt MM?
> Maybe som
On 7 October 2015 at 17:40, Mario Smarduch wrote:
> On 10/7/2015 12:07 AM, Peter Maydell wrote:
>> 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
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 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 13 October 2015 at 13:02, Pavel Fedin wrote:
> Hello!
>
>> b) Once you're in the device state saving (a above) you must not change
>> guest RAM,
>> because at that point the migration code won't send any new changes
>> across
>> to the destination. So any sync's you're going to d
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 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 gic_write_grpen1(1);
>> > +
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
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 ha
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
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 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:
> 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:
> 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:
> 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 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 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 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 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 8 January 2016 at 03:06, Shannon Zhao wrote:
>
>
> On 2016/1/7 22:56, Peter Maydell wrote:
>>>>> + Errors:
>>>>> >>> +-ENXIO: Unsupported attribute group
>>>>> >>> +-EBUSY: The PMU overflow interrupt is alrea
On 8 January 2016 at 12:15, Shannon Zhao wrote:
> Firstly, userspace will call kvm device ioctl to create the PMU device, if
> it fails it will return an error.
> Secondly, userspace will call SET_DEVICE_ATTR ioctl to configure the PMU irq
> number. If the irq is invalid, this will return an error
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.
>From QEMU's point of vie
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 as such we're bound t
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 if we can get guest-virt
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 value from guest VA",
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, "translate guest VA to host VA
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
> other suggestion, I will chang
configuring the PMUv3, call the vcpu iotcl with attribute
> KVM_ARM_VCPU_PMU_V3_INIT to initialize the PMUv3.
>
> Signed-off-by: Shannon Zhao
> ---
> CC: Peter Maydell
> ---
> Documentation/virtual/kvm/devices/vcpu.txt | 24 ++
> arch/arm/include/asm/kvm_host.
On 28 November 2016 at 11:12, Alex Bennée wrote:
>
> Andrew Jones writes:
>> I've skimmed over everything looking at it from a framwork/sytle
>> perspective. I didn't dig in trying to understand the tests though.
>> One general comment, I see many tests introduce MAX_CPUS 8. Why do
>> that? Why n
On 28 November 2016 at 11:58, Andrew Jones wrote:
> On Mon, Nov 28, 2016 at 11:14:48AM +0000, Peter Maydell wrote:
>> On 28 November 2016 at 11:12, Alex Bennée wrote:
>> >
>> > Andrew Jones writes:
>> >> I've skimmed over everything looking at i
On 28 November 2016 at 14:07, Andrew Jones wrote:
> Er... actually mach-virt is 123, as we only allocate 123 redistributors.
Oh yes, I'd forgotten about that limit. We'd need to add
a KVM API for allocating redistributors in non-contiguous
bits of memory if we wanted to raise that.
thanks
-- PMM
On 29 November 2016 at 21:09, Christoffer Dall
wrote:
> Actually, I'm not sure what the semantics of the line level ioctl should
> be for edge-triggered interrupts? My inclination is that it shouldn't
> have any effect at this point, but that would mean that at this point we
> should only set the
On 30 November 2016 at 08:24, Christoffer Dall
wrote:
> (Peter, I thought you once argued that it was important for user space
> to be able to save/restore the state without any ordering requirements,
> but I may have misunderstood. It is still the option to add something
> like the above to the
On 1 December 2016 at 11:28, Andre Przywara wrote:
> I don't think so. At least here as a _variable_ type uint32_t is
> probably the right one, as the ARMv8 ARM explicitly says that PMCR is a
> 32-bit register, for both bitnesses.
For 64-bit ARM this is strictly speaking just shorthand for "64-bi
1 - 100 of 360 matches
Mail list logo
