Hi Sebastian,
On 8/13/19 1:58 PM, bige...@linutronix.de wrote:
On 2019-07-27 14:37:11 [+0100], Julien Grall wrote:
8<
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -80,7 +80,7 @@ static inline bool userspace_irqchip(str
static void soft_timer_start(struct
On Tue, 13 Aug 2019 16:44:21 +0100,
Julien Grall wrote:
>
> Hi Sebastian,
>
> On 8/13/19 1:58 PM, bige...@linutronix.de wrote:
> > On 2019-07-27 14:37:11 [+0100], Julien Grall wrote:
> 8<
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@
Hi,
On 8/13/19 4:17 PM, Marc Zyngier wrote:
> On Tue, 13 Aug 2019 09:50:27 +0100,
> Zenghui Yu wrote:
>
> Hi Zenghui,
>
>>
>> Hi folks,
>>
>> Since commit e25028c8ded0 ("KVM: arm/arm64: Bump VGIC_V3_MAX_CPUS to
>> 512"), we seemed to be allowed to boot a 512U guest. But I failed to
>> start
From: Marc Zyngier
[ Upstream commit 03fdfb2690099c19160a3f2c5b77db60b3afeded ]
At the moment, the way we reset system registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.
The "fun" thing is that this can happen while
From: Marc Zyngier
[ Upstream commit c69509c70aa45a8c4954c88c629a64acf4ee4a36 ]
At the moment, the way we reset CP15 registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.
The "fun" thing is that this can happen while
From: Marc Zyngier
[ Upstream commit 03fdfb2690099c19160a3f2c5b77db60b3afeded ]
At the moment, the way we reset system registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.
The "fun" thing is that this can happen while
From: Marc Zyngier
[ Upstream commit c69509c70aa45a8c4954c88c629a64acf4ee4a36 ]
At the moment, the way we reset CP15 registers is mildly insane:
We write junk to them, call the reset functions, and then check that
we have something else in them.
The "fun" thing is that this can happen while
On 2019/8/12 18:39, Steven Price wrote:
On 09/08/2019 14:51, Zenghui Yu wrote:
[...]
Hi Steven,
Since userspace is not involved yet (right?), no one will create the
PV_TIME device for guest (and no one will specify the IPA of the shared
stolen time region), and I guess we will get a "not
Hi folks,
Since commit e25028c8ded0 ("KVM: arm/arm64: Bump VGIC_V3_MAX_CPUS to
512"), we seemed to be allowed to boot a 512U guest. But I failed to
start it up with the latest QEMU. I guess there are at least *two*
reasons (limitations).
First I got a QEMU abort:
"kvm_set_irq: Invalid
On Tue, 13 Aug 2019 09:50:27 +0100,
Zenghui Yu wrote:
Hi Zenghui,
>
> Hi folks,
>
> Since commit e25028c8ded0 ("KVM: arm/arm64: Bump VGIC_V3_MAX_CPUS to
> 512"), we seemed to be allowed to boot a 512U guest. But I failed to
> start it up with the latest QEMU. I guess there are at least
On 2019-07-27 14:37:11 [+0100], Julien Grall wrote:
> > > 8<
> > > --- a/virt/kvm/arm/arch_timer.c
> > > +++ b/virt/kvm/arm/arch_timer.c
> > > @@ -80,7 +80,7 @@ static inline bool userspace_irqchip(str
> > > static void soft_timer_start(struct hrtimer *hrt, u64 ns)
> > > {
> > >
11 matches
Mail list logo