notifier
whose role will be to bind the dynamic sysbus devices. Indeed
dynamic sysbus devices are created after machine init.
machvirt also registers a notifier that will build the device
tree nodes for the platform bus and its children dynamic sysbus
devices.
Signed-off-by: Alexander Graf
Hrm, are
On 04/24/2015 09:36 AM, Baptiste Reynal wrote:
I think it will be a pity to postpone VFIO support on QEMU and would
rather introduce the support for VIRT_MMIO later.
Alex, what is your position on it ?
Ah, sorry, I read this mail too late. Converting virtio-mmio to a
dynamic sysbus device sho
On 04/27/2015 03:56 PM, Peter Maydell wrote:
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
On 04/27/2015 06:58 PM, Christopher Covington wrote:
Hi Alex,
On 04/27/2015 09:41 AM, Alexander Graf wrote:
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -131,6 +138,7 @@ static const MemMapEntry a15memmap[] = {
[VIRT_FW_CFG] = { 0x0902, 0x000a },
[VIRT_MMIO
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 maps that region as uncached for userspace as well,
> in o
On 18.03.15 20:18, Andrew Jones wrote:
> On Wed, Mar 18, 2015 at 03:08:20PM -0400, Andrew Jones wrote:
>> In reply to this message I'll send two series' one for KVM and
>> one for QEMU. The two series' are their respective component
>> complements, and attempt to implement cache coherency for arm
> Am 01.09.2015 um 17:29 schrieb Eric Auger :
>
> Dear all,
>
> I am currently investigating the usage of sysfs to retrieve info from
> the host device tree to build guest dt node for assigned devices (just
> to explain a bit of context for Peter & Alex added in cc). For more
> complex devices
On 16/11/2016 16:54, Andrew Jones wrote:
On Mon, Sep 19, 2016 at 04:52:01PM +0200, Andrew Jones wrote:
On Mon, Sep 19, 2016 at 01:44:40PM +0200, Alexander Graf wrote:
All virtualization capable ARM cores support the ARM architected virtual timer.
This patch adds minimalistic checks whether
we lose out on for example
timer and PMU events if we run with user space gic emulation.
Define an ABI to publish such device output levels to userspace.
Signed-off-by: Alexander Graf
Signed-off-by: Christoffer Dall
Acked-by: Peter Maydell
for the userspace ABI/docs part.
Given Peter
On 05.04.17 11:28, Christoffer Dall wrote:
From: Alexander Graf
If you're running with a userspace gic or other interrupt constroller
(that is no vgic in the kernel), then you have so far not been able to
use the architected timers, because the output of the architected
timers, whic
On 06.04.17 10:25, Marc Zyngier wrote:
On 06/04/17 09:16, Alexander Graf wrote:
On 05.04.17 11:28, Christoffer Dall wrote:
From: Alexander Graf
@@ -559,6 +628,13 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
if (timer->enabled)
return 0;
+ /* Withou
On 05.04.17 11:28, Christoffer Dall wrote:
This series is the second version of the rework of the patches to support
architected timers with a userspace irqchip sent by Alexander Graf [1].
We first cleanup some of the timer code to make it easier to understand
what is being done in the later
On 04.04.17 12:35, Suzuki K Poulose wrote:
Hi Christoffer,
On 04/04/17 11:13, Christoffer Dall wrote:
Hi Suzuki,
On Mon, Apr 03, 2017 at 03:12:43PM +0100, Suzuki K Poulose wrote:
In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
unmap_stage2_range() on the entire memory
not, but let's assume it's a different
issue for now.
Tested-by: Alexander Graf
Alex
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
ase()
kvm_arch_flush_shadow_all()
kvm_free_stage2_pgd()
stage2_get_pmd()
set kvm->arch.pgd = 0
stage2_get_pud()
arch.pgd>
This patch adds a check for that case.
Signed-off-by: Alexander Graf
---
vir
On 07/03/2017 10:03 AM, Christoffer Dall wrote:
Hi Alex,
On Fri, Jun 23, 2017 at 05:21:59PM +0200, Alexander Graf wrote:
If we want to age an HVA while the VM is getting destroyed, we have a
tiny race window during which we may end up dereferencing an invalid
kvm->arch.pgd value.
C
e a NULL pgd pointer.
This patch adds a check for that case, so that we leave the aging
function silently.
Cc: sta...@vger.kernel.org
Fixes: 293f29363 ("kvm-arm: Unmap shadow pagetables properly")
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Fix commit message
- Add Fixes
On 05.07.17 10:57, Suzuki K Poulose wrote:
Hi Alex,
On Wed, Jul 05, 2017 at 08:20:31AM +0200, Alexander Graf wrote:
The kvm_age_hva callback may be called all the way concurrently while
kvm_mmu_notifier_release() is running.
The release function sets kvm->arch.pgd = NULL which the ag
On 17.07.17 20:23, Christoffer Dall wrote:
On Mon, Jul 17, 2017 at 05:16:17PM +0200, Andrea Arcangeli wrote:
On Mon, Jul 17, 2017 at 04:45:10PM +0200, Christoffer Dall wrote:
I would also very much like to get to the bottom of this, and at the
very least try to get a valid explanation as to h
On 19.02.15 11:54, Ard Biesheuvel wrote:
> This is a 0th order approximation of how we could potentially force the guest
> to avoid uncached mappings, at least from the moment the MMU is on. (Before
> that, all of memory is implicitly classified as Device-nGnRnE)
>
> The idea (patch #2) is to tr
On 19.02.15 15:56, Ard Biesheuvel wrote:
> On 19 February 2015 at 14:50, Alexander Graf wrote:
>>
>>
>> On 19.02.15 11:54, Ard Biesheuvel wrote:
>>> This is a 0th order approximation of how we could potentially force the
>>> guest
>>> to avoid
On 02/19/2015 11:54 AM, Ard Biesheuvel wrote:
This is a 0th order approximation of how we could potentially force the guest
to avoid uncached mappings, at least from the moment the MMU is on. (Before
that, all of memory is implicitly classified as Device-nGnRnE)
The idea (patch #2) is to trap wr
On 10/23/2017 06:11 PM, Marc Zyngier wrote:
The only case where we actually need to perform a dcache maintenance
is when we map the page for the first time, and subsequent permission
faults do not require cache maintenance. Let's make it conditional
on not being a permission fault (and thus a tra
On 08/21/2018 03:35 PM, Alexander Graf wrote:
On 10/23/2017 06:11 PM, Marc Zyngier wrote:
The only case where we actually need to perform a dcache maintenance
is when we map the page for the first time, and subsequent permission
faults do not require cache maintenance. Let's make it condit
On 08/21/2018 03:57 PM, Marc Zyngier wrote:
On 21/08/18 14:35, Alexander Graf wrote:
On 10/23/2017 06:11 PM, Marc Zyngier wrote:
The only case where we actually need to perform a dcache maintenance
is when we map the page for the first time, and subsequent permission
faults do not require
On 08/21/2018 04:08 PM, Alexander Graf wrote:
On 08/21/2018 03:57 PM, Marc Zyngier wrote:
On 21/08/18 14:35, Alexander Graf wrote:
On 10/23/2017 06:11 PM, Marc Zyngier wrote:
The only case where we actually need to perform a dcache maintenance
is when we map the page for the first time, and
On 08/21/2018 05:08 PM, Marc Zyngier wrote:
On 21/08/18 15:08, Alexander Graf wrote:
On 08/21/2018 03:57 PM, Marc Zyngier wrote:
On 21/08/18 14:35, Alexander Graf wrote:
On 10/23/2017 06:11 PM, Marc Zyngier wrote:
The only case where we actually need to perform a dcache maintenance
is when
On 08/23/2018 01:16 PM, Marc Zyngier wrote:
On 21/08/18 17:54, Alexander Graf wrote:
On 08/21/2018 05:08 PM, Marc Zyngier wrote:
On 21/08/18 15:08, Alexander Graf wrote:
On 08/21/2018 03:57 PM, Marc Zyngier wrote:
On 21/08/18 14:35, Alexander Graf wrote:
On 10/23/2017 06:11 PM, Marc Zyngier
On 23.08.18 14:43, Marc Zyngier wrote:
> On 23/08/18 13:24, Alexander Graf wrote:
>> On 08/23/2018 01:16 PM, Marc Zyngier wrote:
>>> On 21/08/18 17:54, Alexander Graf wrote:
>>>> On 08/21/2018 05:08 PM, Marc Zyngier wrote:
>>>>> On 21/08/18 15:08, Ale
Hi Marc,
On 10.03.20 19:00, Marc Zyngier wrote:
On 2020-03-10 17:40, Auger Eric wrote:
Hi Marc,
On 3/10/20 12:03 PM, Marc Zyngier wrote:
Hi Eric,
On 2020-03-09 18:05, Auger Eric wrote:
Hi Marc,
On 3/9/20 1:48 PM, Marc Zyngier wrote:
It can be desirable to expose a PMU to a guest, and yet
On 11.07.19 11:42, Andre Przywara wrote:
On Thu, 11 Jul 2019 09:52:42 +0200
Paolo Bonzini wrote:
Hi,
On 11/07/19 07:49, Alexander Graf wrote:
I agree that it would belong more in qtest, but tests in not exactly the
right place is better than no tests.
The problem with qtest is that it
On 10.07.19 16:25, Marc Zyngier wrote:
Hi Alex,
I don't know much about pl031, so my comments are pretty general...
On 10/07/2019 14:27, Alexander Graf wrote:
This patch adds a unit test for the PL031 RTC that is used in the virt machine.
It just pokes basic functionality. I'
ff-by: Alexander Graf
---
v1 -> v2:
- Use FDT to find base, irq and existence
- Put isb after timer read
- Use dist_base for gicv3
---
arm/Makefile.common | 1 +
arm/pl031.c | 265
lib/arm/asm/gic.h | 1 +
3 files changed, 267 in
On 25.07.19 15:25, Andrew Jones wrote:
On Thu, Jul 25, 2019 at 03:09:49PM +0200, Alexander Graf wrote:
This patch adds a unit test for the PL031 RTC that is used in the virt machine.
It just pokes basic functionality. I've mostly written it to familiarize myself
with the device,
On 05.08.19 15:06, Steven Price wrote:
On 03/08/2019 19:05, Marc Zyngier wrote:
On Fri, 2 Aug 2019 15:50:08 +0100
Steven Price wrote:
Hi Steven,
This series add support for paravirtualized time for arm64 guests and
KVM hosts following the specification in Arm's document DEN 0057A:
https
On 14.08.19 16:19, Marc Zyngier wrote:
On Wed, 14 Aug 2019 14:02:25 +0100,
Alexander Graf wrote:
On 05.08.19 15:06, Steven Price wrote:
On 03/08/2019 19:05, Marc Zyngier wrote:
On Fri, 2 Aug 2019 15:50:08 +0100
Steven Price wrote:
Hi Steven,
This series add support for
On 06.09.19 10:00, Christoffer Dall wrote:
On Thu, Sep 05, 2019 at 02:09:18PM +0100, Marc Zyngier wrote:
On 05/09/2019 10:22, Christoffer Dall wrote:
On Thu, Sep 05, 2019 at 09:56:44AM +0100, Peter Maydell wrote:
On Thu, 5 Sep 2019 at 09:52, Marc Zyngier wrote:
On Thu, 05 Sep 2019 09:16:5
On 06.09.19 14:34, Marc Zyngier wrote:
On 06/09/2019 13:08, Alexander Graf wrote:
On 06.09.19 10:00, Christoffer Dall wrote:
On Thu, Sep 05, 2019 at 02:09:18PM +0100, Marc Zyngier wrote:
[...]
@@ -673,6 +694,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
kvm_run *run
On 06.09.19 15:12, Christoffer Dall wrote:
On Fri, Sep 06, 2019 at 02:08:15PM +0200, Alexander Graf wrote:
On 06.09.19 10:00, Christoffer Dall wrote:
On Thu, Sep 05, 2019 at 02:09:18PM +0100, Marc Zyngier wrote:
On 05/09/2019 10:22, Christoffer Dall wrote:
On Thu, Sep 05, 2019 at 09:56
On 06.09.19 15:50, Peter Maydell wrote:
On Fri, 6 Sep 2019 at 14:41, Alexander Graf wrote:
On 06.09.19 15:31, Peter Maydell wrote:
(b) we try to reuse the code we already have that does TCG exception
injection, which might or might not be a design mistake, and
That's probably a d
rt the timer for the remaining time when the condition
is detected.
This patch implements the latter, with a bit of refactoring in
order to avoid too much code duplication.
Reported-by: Alexander Graf
Signed-off-by: Marc Zyngier
Looks good, I can give it a test run later as well, but for now
Reviewe
rt the timer for the remaining time when the condition
is detected.
This patch implements the latter, with a bit of refactoring in
order to avoid too much code duplication.
Reported-by: Alexander Graf
Signed-off-by: Marc Zyngier
Oh - before I forget. This should go out with
On 30.11.15 10:40, Pavel Fedin wrote:
> Before commit 662d9715840aef44dcb573b0f9fab9e8319c868a
> ("arm/arm64: KVM: Kill CONFIG_KVM_ARM_{VGIC,TIMER}") is was possible to
> compile the kernel without vGIC and vTimer support. Commit message says
> about possibility to detect vGIC support in runtime,
On 22.04.16 00:04, Peter Maydell wrote:
> 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
> Am 24.06.2016 um 20:16 schrieb Ard Biesheuvel :
>
>> On 24 June 2016 at 16:04, Ard Biesheuvel wrote:
>> [...]
>> Note that this issue not only affects framebuffers on PCI cards, it
>> also affects emulated USB host controllers (perhaps Alex can remind us
>> which one exactly?)
>
> Actually,
> Am 24.06.2016 um 16:04 schrieb Ard Biesheuvel :
>
> Hi all,
>
> This old subject came up again in a discussion related to PCIe support
> for QEMU/KVM under Tianocore. The fact that we need to map PCI MMIO
> regions as cacheable is preventing us from reusing a significant slice
> of the PCIe s
> Am 27.06.2016 um 12:34 schrieb Christoffer Dall :
>
>> On Mon, Jun 27, 2016 at 11:47:18AM +0200, Ard Biesheuvel wrote:
>>> On 27 June 2016 at 11:16, Christoffer Dall
>>> wrote:
>>> Hi,
>>>
>>> I'm going to ask some stupid questions here...
>>>
On Fri, Jun 24, 2016 at 04:04:45PM +0200,
> Am 27.06.2016 um 15:57 schrieb Ard Biesheuvel :
>
>> On 27 June 2016 at 15:35, Christoffer Dall
>> wrote:
>>> On Mon, Jun 27, 2016 at 02:30:46PM +0200, Ard Biesheuvel wrote:
On 27 June 2016 at 12:34, Christoffer Dall
wrote:
> On Mon, Jun 27, 2016 at 11:47:18AM +0200, Ard Bies
On 06/28/2016 12:55 PM, Laszlo Ersek wrote:
On 06/27/16 12:34, Christoffer Dall wrote:
On Mon, Jun 27, 2016 at 11:47:18AM +0200, Ard Biesheuvel wrote:
So first of all, let me reiterate that I could only find a single
instance in QEMU where a PCI MMIO region is backed by host memory,
which is
.
Signed-off-by: Alexander Graf
---
A branch with WIP QEMU code can be found here:
https://github.com/agraf/qemu.git no-kvm-irqchip
---
Documentation/virtual/kvm/api.txt | 28 -
arch/arm/include/asm/kvm_host.h | 3 +
arch/arm/kvm/arm.c| 46 +++---
arch/arm64
.
Signed-off-by: Alexander Graf
---
A branch with WIP QEMU code can be found here:
https://github.com/agraf/qemu.git no-kvm-irqchip
v1 -> v2:
- Add back curly brace that got lost
---
Documentation/virtual/kvm/api.txt | 28 -
arch/arm/include/asm/kvm_host.h | 3 +
arch/arm/
.
Signed-off-by: Alexander Graf
---
A branch with WIP QEMU code can be found here:
https://github.com/agraf/qemu.git no-kvm-irqchip
v1 -> v2:
- Add back curly brace that got lost (and is very stubborn, sorry for
the resubmit to actually add it back for real)
---
Documentation/virtual/
0x288
[ 74.941406] [] kvm_arch_vcpu_ioctl_run+0xfc/0x630
[ 74.947766] [] kvm_vcpu_ioctl+0x2f4/0x710
[ 74.953420] [] do_vfs_ioctl+0xb0/0x728
[ 74.958807] [] SyS_ioctl+0x94/0xa8
[ 74.963844] [] el0_svc_naked+0x38/0x3c
Fixes: 0919e84c0
Cc: sta...@vger.kernel.org
Signed-off-by: Alexander
In a follow-up patch we will need to enable capabilities on demand for
backwards compatibility. This patch adds the generic framework to handle
vcpu cap enablement to the arm code base.
Signed-off-by: Alexander Graf
---
Documentation/virtual/kvm/api.txt | 4 +++-
arch/arm/kvm/arm.c
no-kvm-irqchip
To use the user space irqchip, just run it with
$ qemu-system-aarch64 -M virt,kernel-irqchip=off
v1 -> v2:
- Add back curly brace that got lost
v2 -> v3:
- Fix "only only" in documentation
- Split patches
- Remove kvm_emulate.h include
Alexander Graf
-off-by: Alexander Graf
---
v1 -> v2:
- Add back curly brace that got lost
v2 -> v3:
- Split into patch set
---
Documentation/virtual/kvm/api.txt | 24 +++-
arch/arm/include/asm/kvm_host.h | 3 +
arch/arm/kvm/arm.c| 22 ---
arch/arm64/include/asm/kvm_
> On 16 Sep 2016, at 11:11, Peter Maydell wrote:
>
> On 16 September 2016 at 07:26, Alexander Graf wrote:
>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>> handle them all using hardware acceleration through the vgic or we can
>> emu
> On 16 Sep 2016, at 12:20, Marc Zyngier wrote:
>
> Hi Alex,
>
> On 16/09/16 07:26, Alexander Graf wrote:
>> Some systems out there (well, one type in particular - the Raspberry Pi
>> series)
>> do have virtualization capabilities in the core, but no ARM GIC i
> On 16 Sep 2016, at 11:44, Christoffer Dall
> wrote:
>
> Alex,
>
> On Fri, Sep 16, 2016 at 07:09:13AM +0200, Alexander Graf wrote:
>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>> handle them all using hardware accelerat
> On 16 Sep 2016, at 14:29, Christoffer Dall
> wrote:
>
> On Fri, Sep 16, 2016 at 02:25:01PM +0200, Alexander Graf wrote:
>>
>>> On 16 Sep 2016, at 12:20, Marc Zyngier wrote:
>>>
>>> Hi Alex,
>>>
>>> On 16/09/16 07:26, Alexa
> On 16 Sep 2016, at 14:40, Paolo Bonzini wrote:
>
>
>
> On 16/09/2016 14:29, Christoffer Dall wrote:
>>> It may be useful for migrating a gicv2 VM to a gicv3 host without gicv2
>>> emulation as well.
>>
>> I don't see why you'd do this; the VGIC hardware can perfectly well be
>> used for ne
> Am 16.09.2016 um 15:46 schrieb Andrew Jones :
>
>> On Fri, Sep 16, 2016 at 03:30:27PM +0200, Christoffer Dall wrote:
>>> On Fri, Sep 16, 2016 at 02:31:42PM +0200, Paolo Bonzini wrote:
>>>
>>>
>>> On 16/09/2016 14:30, Christoffer Dall wrote:
>>> This patch set allows user space to receive
On 16.09.16 15:30, Christoffer Dall wrote:
> On Fri, Sep 16, 2016 at 02:31:42PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 16/09/2016 14:30, Christoffer Dall wrote:
>> This patch set allows user space to receive vtimer events as well as mask
>> them, so that we can handle all vtimer related
-off-by: Alexander Graf
---
v1 -> v2:
- Add back curly brace that got lost
v2 -> v3:
- Split into patch set
v3 -> v4:
- Improve documentation
---
Documentation/virtual/kvm/api.txt | 30 -
arch/arm/include/asm/kvm_host.h | 3 +
arch/arm/kvm/arm.c
ot;only only" in documentation
- Split patches
- Remove kvm_emulate.h include
v3 -> v4:
- Improve documentation
Alexander Graf (2):
KVM: arm/arm64: Add vcpu ENABLE_CAP functionality
KVM: arm/arm64: Route vtimer events to user space
Documentation/virtual/kvm/api.txt | 34 +
In a follow-up patch we will need to enable capabilities on demand for
backwards compatibility. This patch adds the generic framework to handle
vcpu cap enablement to the arm code base.
Signed-off-by: Alexander Graf
---
Documentation/virtual/kvm/api.txt | 4 +++-
arch/arm/kvm/arm.c
pin is marked as
pending on the GIC.
Signed-off-by: Alexander Graf
---
arm/Makefile.arm64 | 2 +-
arm/vtimer-test.c | 122 +
2 files changed, 123 insertions(+), 1 deletion(-)
create mode 100644 arm/vtimer-test.c
diff --git a/arm
On 19.09.16 09:52, Andrew Jones wrote:
> On Fri, Sep 16, 2016 at 09:36:42PM +0200, Alexander Graf wrote:
>>
>>
>>> Am 16.09.2016 um 15:46 schrieb Andrew Jones :
>>>
>>>> On Fri, Sep 16, 2016 at 03:30:27PM +0200, Christoffer Dall wrote:
>>
On 19.09.16 16:48, Marc Zyngier wrote:
> On 19/09/16 12:14, Alexander Graf wrote:
>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>> handle them all using hardware acceleration through the vgic or we can
>> emulate
>> a gic in user s
On 20.09.16 11:21, Marc Zyngier wrote:
> On 19/09/16 18:39, Alexander Graf wrote:
>>
>>
>> On 19.09.16 16:48, Marc Zyngier wrote:
>>> On 19/09/16 12:14, Alexander Graf wrote:
>>>> We have 2 modes for dealing with interrupts in the ARM world. We can
On 09/20/2016 11:39 AM, Marc Zyngier wrote:
On 20/09/16 10:26, Alexander Graf wrote:
On 20.09.16 11:21, Marc Zyngier wrote:
On 19/09/16 18:39, Alexander Graf wrote:
On 19.09.16 16:48, Marc Zyngier wrote:
On 19/09/16 12:14, Alexander Graf wrote:
We have 2 modes for dealing with interrupts
On 09/20/2016 12:28 PM, Marc Zyngier wrote:
On 20/09/16 11:05, Alexander Graf wrote:
On 09/20/2016 11:39 AM, Marc Zyngier wrote:
On 20/09/16 10:26, Alexander Graf wrote:
On 20.09.16 11:21, Marc Zyngier wrote:
On 19/09/16 18:39, Alexander Graf wrote:
On 19.09.16 16:48, Marc Zyngier wrote
On 09/20/2016 02:37 PM, Marc Zyngier wrote:
On 20/09/16 13:22, Alexander Graf wrote:
On 09/20/2016 12:28 PM, Marc Zyngier wrote:
On 20/09/16 11:05, Alexander Graf wrote:
On 09/20/2016 11:39 AM, Marc Zyngier wrote:
On 20/09/16 10:26, Alexander Graf wrote:
On 20.09.16 11:21, Marc Zyngier
On 09/20/2016 06:42 PM, Marc Zyngier wrote:
On 20/09/16 15:31, Alexander Graf wrote:
On 09/20/2016 02:37 PM, Marc Zyngier wrote:
[...]
We also need to know "timer line low + timer line masked", as otherwise
we might get spurious interrupts in the guest, no?
Yes. Though you can
On 09/20/2016 11:21 AM, Marc Zyngier wrote:
On 19/09/16 18:39, Alexander Graf wrote:
On 19.09.16 16:48, Marc Zyngier wrote:
+
+ /*
+* So we can just explicitly mask or unmask the IRQ, gaining
+* more compatibility with oddball irq controllers
Linux with user space gic
emulation.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Add back curly brace that got lost
v2 -> v3:
- Split into patch set
v3 -> v4:
- Improve documentation
v4 -> v5:
- Rewrite to use pending state sync in sregs (marc)
- Remove re
On 22.09.16 23:28, Christoffer Dall wrote:
> On Thu, Sep 22, 2016 at 02:52:49PM +0200, Alexander Graf wrote:
>> We have 2 modes for dealing with interrupts in the ARM world. We can either
>> handle them all using hardware acceleration through the vgic or we can
>> emulate
&
On 23.09.16 10:57, Paolo Bonzini wrote:
>
>
> On 23/09/2016 09:14, Alexander Graf wrote:
>>>> +/*
>>>> + * Synchronize the timer IRQ state with the interrupt controller.
>>>> + */
>>>> static void kvm_timer_update_irq(struc
On 23.09.16 11:15, Paolo Bonzini wrote:
>
>
> On 23/09/2016 11:10, Alexander Graf wrote:
>>>>> Maybe I'm misunderstanding and user_timer_pending is just a cached
>>>>> verison of what you said last, but as I said above, I think you can just
>&g
I can successfully run edk2 and Linux with user space gic
emulation.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Add back curly brace that got lost
v2 -> v3:
- Split into patch set
v3 -> v4:
- Improve documentation
v4 -> v5:
- Rewrite to use pending state sync in sregs
> Am 23.09.2016 um 14:11 schrieb Paolo Bonzini :
>
>
>
>> On 23/09/2016 13:07, Alexander Graf wrote:
>> +timer_ret = kvm_timer_sync_hwstate(vcpu);
>>
>>kvm_vgic_sync_hwstate(vcpu);
>>
>>preempt_enable()
I can successfully run edk2 and Linux with user space gic
emulation.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- Add back curly brace that got lost
v2 -> v3:
- Split into patch set
v3 -> v4:
- Improve documentation
v4 -> v5:
- Rewrite to use pending state sync in sregs
On 09/27/2016 09:08 PM, Christoffer Dall wrote:
Hi Alex,
Marc and I have been looking at this during Linaro connect and have
slightly reworked your patch into this small series.
It would be good if you could have a look at it and test it out.
Tested-by: Alexander Graf
Works fine so far
On 27.09.16 21:08, Christoffer Dall wrote:
> Hi Alex,
>
> Marc and I have been looking at this during Linaro connect and have
> slightly reworked your patch into this small series.
>
> It would be good if you could have a look at it and test it out.
>
> I've tested it with your QEMU, and it wo
On 30.09.16 16:54, Alexander Graf wrote:
>
>
> On 27.09.16 21:08, Christoffer Dall wrote:
>> Hi Alex,
>>
>> Marc and I have been looking at this during Linaro connect and have
>> slightly reworked your patch into this small series.
>>
>> It would be
On 30.09.16 17:43, Christoffer Dall wrote:
> On Fri, Sep 30, 2016 at 05:38:11PM +0200, Alexander Graf wrote:
>>
>>
>> On 30.09.16 16:54, Alexander Graf wrote:
>>>
>>>
>>> On 27.09.16 21:08, Christoffer Dall wrote:
>>>> Hi Alex,
>>
On 30.09.16 17:43, Christoffer Dall wrote:
> On Fri, Sep 30, 2016 at 05:38:11PM +0200, Alexander Graf wrote:
>>
>>
>> On 30.09.16 16:54, Alexander Graf wrote:
>>>
>>>
>>> On 27.09.16 21:08, Christoffer Dall wrote:
>>>> Hi Alex,
>>
On 10.10.16 15:50, Marc Zyngier wrote:
> On 2016-10-06 19:54, Eugene Bagdasaryan wrote:
>> Hey Marc
>>
>> I basically want to try and install OpenStack on RPi, which I guess
>> is possible.
>
> Sounds pretty ambitious, but I guess someone has to try...
>
>> (1) For the 64-bit arm OS, what would
> Am 28.10.2016 um 16:38 schrieb Marc Zyngier :
>
> Alex,
>
>> On 30/09/16 20:31, Alexander Graf wrote:
>>
>>
>>> On 30.09.16 17:43, Christoffer Dall wrote:
>>>> On Fri, Sep 30, 2016 at 05:38:11PM +0200, Alexander Graf wrote:
>&g
> Am 28.10.2016 um 17:57 schrieb Marc Zyngier :
>
>> On 28/10/16 16:52, Alexander Graf wrote:
>>
>>
>>> Am 28.10.2016 um 16:38 schrieb Marc Zyngier :
>>>
>>> Alex,
>>>
>>>> On 30/09/16 20:31, Alexander Graf wrote:
>
> On 29 Oct 2016, at 15:19, Paolo Bonzini wrote:
>
> What the status of userspace for this thing? Are QEMU patches being
> posted and reviewed?
I didn't see a notification that the patches were merged. Are they in
Linus' tree yet? Then I can post enablement to qemu-devel.
emulation, we miss out on
timer events which are only available from kernel space. This patch leverages
the new kernel/user space pending line synchronization for those timer events.
Signed-off-by: Alexander Graf
---
hw/arm/virt.c| 10 ++
target-arm/cpu.h | 3 +++
target-arm/kvm.c | 19
This patch updates the Linux headers to include the in-progress user
space ARM timer patches. It is explicitly RFC, as the patches are not
merged yet.
---
linux-headers/asm-arm/kvm.h | 1 +
linux-headers/asm-arm64/kvm.h | 1 +
linux-headers/linux/kvm.h | 6 ++
3 files changed, 8 insertio
On 01/11/2016 11:19, Peter Maydell wrote:
On 29 October 2016 at 22:10, Alexander Graf wrote:
This patch updates the Linux headers to include the in-progress user
space ARM timer patches. It is explicitly RFC, as the patches are not
merged yet.
---
Is there a cover letter email for this
On 11/01/2016 12:35 PM, Peter Maydell wrote:
On 29 October 2016 at 22:10, Alexander Graf wrote:
When running with KVM enabled, you can choose between emulating the
gic in kernel or user space. If the kernel supports in-kernel virtualization
of the interrupt controller, it will default to that
On 11/02/2016 05:19 PM, Christoffer Dall wrote:
On Wed, Nov 02, 2016 at 04:40:35PM +0100, Alexander Graf wrote:
On 11/01/2016 12:35 PM, Peter Maydell wrote:
On 29 October 2016 at 22:10, Alexander Graf wrote:
[...]
+cpu->timer_irq_level = run->s.regs.timer_irq
96 matches
Mail list logo