In our Armv8a server (qualcomm Amberwing, non VHE), after applying
Christoffer's timer optimizing patchset(Optimize arch timer register
handling), the guest is hang during kernel booting.
The error root cause might be as follows:
1. in kvm_arch_timer_handler, it reset vtimer->cnt_ctl with current
On 12 December 2017 at 18:32, James Morse wrote:
> As this is over my head, I've been pushing random encodings through
> gas/objdump
> and then tracing them through here can this encode 0xf8000fff?
>
> gas thinks this is legal:
> | 0: 92458000and x0, x0, #0xf8000ff
On Tue, Dec 12, 2017 at 09:40:10AM +0100, Auger Eric wrote:
>
>
> On 11/12/17 21:51, Auger Eric wrote:
> > Hi Christoffer,
> > On 07/12/17 11:54, Christoffer Dall wrote:
> >> The timer was modeled after a strict idea of modelling an interrupt line
> >> level in software, meaning that only transit
On Tue, Dec 12, 2017 at 3:11 AM, Dave Martin wrote:
> On Tue, Dec 12, 2017 at 10:40:30AM +, Will Deacon wrote:
>> On Mon, Dec 11, 2017 at 11:23:09AM -0800, Kees Cook wrote:
>> > On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon wrote:
>> > > On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrot
On 11 December 2017 at 14:49, Marc Zyngier wrote:
> We lack a way to encode operations such as AND, ORR, EOR that take
> an immediate value. Doing so is quite involved, and is all about
> reverse engineering the decoding algorithm described in the
> pseudocode function DecodeBitMasks().
Is it pos
Hi Marc,
On 11/12/17 14:49, Marc Zyngier wrote:
> We lack a way to encode operations such as AND, ORR, EOR that take
> an immediate value. Doing so is quite involved, and is all about
> reverse engineering the decoding algorithm described in the
> pseudocode function DecodeBitMasks().
As this is
On 11/12/2017 16:22, Christoffer Dall wrote:
> I find the special casing with the immediate return a bit ugly. Maybe
> introduce a helper async_vcpu_ioctl() or so that sets -ENOIOCTLCMD in
> its default case and return here if ret != -ENOIOCTLCMD? Christian,
> what do you think?
I'll post my attem
On 11/12/2017 13:39, Cornelia Huck wrote:
>> +ret = -EINVAL;
>> for (n = 0; n < (KVMPPC_BOOKE_IAC_NUM + KVMPPC_BOOKE_DAC_NUM); n++) {
>> uint64_t addr = dbg->arch.bp[n].addr;
>> uint32_t type = dbg->arch.bp[n].type;
>> @@ -2067,21 +2071,24 @@ int kvm_arch_vcpu_ioc
On 11/12/2017 10:19, Christoffer Dall wrote:
> On Fri, Dec 08, 2017 at 05:26:02PM +0100, David Hildenbrand wrote:
>>
>>>
>>> int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs
>>> *regs)
>>> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
>>> index f647e121
On Tue, Dec 12, 2017 at 01:08:30PM +, Marc Zyngier wrote:
> On 11/12/17 11:24, Christoffer Dall wrote:
> > On Mon, Dec 11, 2017 at 11:10:36AM +, Marc Zyngier wrote:
> >> On 07/12/17 17:06, Christoffer Dall wrote:
> >>> When we defer the save/restore of system registers to vcpu_load and
> >>
Hi Ard,
On Mon, Dec 04, 2017 at 04:01:09PM +, Ard Biesheuvel wrote:
> On 4 December 2017 at 14:13, Steve Capper wrote:
> > update_mapping_prot assumes that it will be used on the VA for the
> > kernel .text section. (Via the check virt >= VMALLOC_START)
> >
> > Recent kdump patches employ thi
On 11/12/17 11:24, Christoffer Dall wrote:
> On Mon, Dec 11, 2017 at 11:10:36AM +, Marc Zyngier wrote:
>> On 07/12/17 17:06, Christoffer Dall wrote:
>>> When we defer the save/restore of system registers to vcpu_load and
>>> vcpu_put, we need to take care of the emulation code that handles trap
On Mon, Dec 04, 2017 at 02:30:28PM +, Suzuki K Poulose wrote:
> On 04/12/17 14:13, Steve Capper wrote:
> > In save_elrsr(.), we use the following technique to ascertain the
> > address of the vgic global state:
> > (kern_hyp_va(&kvm_vgic_global_state))->nr_lr
> >
> > For arm, kern_hyp_va(v
On Mon, Dec 11, 2017 at 08:24:32PM +0100, Christoffer Dall wrote:
> On Mon, Dec 11, 2017 at 02:51:36PM +, Dave Martin wrote:
> > On Fri, Nov 24, 2017 at 03:45:38PM +0100, Christoffer Dall wrote:
[...]
> > > So you're saying even if we try the "expose full width and read back
> > > hidden valu
On Tue, Dec 12, 2017 at 10:40:30AM +, Will Deacon wrote:
> On Mon, Dec 11, 2017 at 11:23:09AM -0800, Kees Cook wrote:
> > On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon wrote:
> > > On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrote:
> > >> My question is mainly: why not just use copy_*()
On Mon, Dec 04, 2017 at 06:12:13PM +, Steve Capper wrote:
> On Mon, Dec 04, 2017 at 05:27:10PM +, Ard Biesheuvel wrote:
> > On 4 December 2017 at 17:18, Steve Capper wrote:
> > > Hi Ard,
> > >
> > > On Mon, Dec 04, 2017 at 04:25:18PM +, Ard Biesheuvel wrote:
> > >> On 4 December 2017 a
On Mon, Dec 11, 2017 at 12:00:22PM +, Catalin Marinas wrote:
> On Mon, Dec 04, 2017 at 02:13:05PM +, Steve Capper wrote:
> > The high_memory global variable is used by
> > cma_declare_contiguous(.) before it is defined.
> >
> > We don't notice this as we compute __pa(high_memory - 1), and
On Mon, Dec 11, 2017 at 11:23:09AM -0800, Kees Cook wrote:
> On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon wrote:
> > On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrote:
> >> My question is mainly: why not just use copy_*() everywhere instead?
> >> Having these things so spread out makes it
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> We currently check if the VM has a userspace irqchip on every exit from
> the VCPU, and if so, we do some work to ensure correct timer behavior.
> This is unfortunate, as we could avoid doing any work entirely, if we
> didn't have to sup
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> The VGIC can now support the life-cycle of mapped level-triggered
> interrupts, and we no longer have to read back the timer state on every
> exit from the VM if we had an asserted timer interrupt signal, because
> the VGIC already knows
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> For mapped IRQs (with the HW bit set in the LR) we have to follow some
> rules of the architecture. One of these rules is that VM must not be
> allowed to deactivate a virtual interrupt with the HW bit set unless the
> physical interrup
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> Level-triggered mapped IRQs are special because we only observe rising
> edges as input to the VGIC, and we don't set the EOI flag and therefore
> are not told when the level goes down, so that we can re-queue a new
> interrupt when the
On 11/12/17 21:51, Auger Eric wrote:
> Hi Christoffer,
> On 07/12/17 11:54, Christoffer Dall wrote:
>> The timer was modeled after a strict idea of modelling an interrupt line
>> level in software, meaning that only transitions in the level needed to
>> be reported to the VGIC. This works well f
Hi Christoffer,
On 07/12/17 11:54, Christoffer Dall wrote:
> The GIC sometimes need to sample the physical line of a mapped
> interrupt. As we know this to be notoriously slow, provide a callback
> function for devices (such as the timer) which can do this much faster
> than talking to the distri
24 matches
Mail list logo
