Re: [RFC] Handling CP15 timer without in-kernel irqchip

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 to >>> emulate part of the CPU even though that CPU support is really

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > How do boards other than 'virt' work when emulated without KVM? Under "emulated without KVM" we normally suppose full software emulation (known in qemu as TCG). In this case CPU code is interpreted, and KVM is not used at all. Some boards (like vexpress) have own platform-specific

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On 02/10/2015 11:58, Peter Maydell wrote: > 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

Re: [RFC] Handling CP15 timer without in-kernel irqchip

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

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > - How do you find out that your guest is Linux? Yes, i agree. No way. And it's not host kernel's job anyway. > - How do you ensure that the guest will not require the virtual timer? Agree again. Except device tree, no way. If the guest has its own hardcoded assumptions, it's

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On Fri, 2 Oct 2015 10:28:42 +0300 Pavel Fedin wrote: [...] > 1. If there's no in-kernel irqchip, we revert to older timer > behavior (ARCH_TIMER_CTRL_IT_MASK hack), and forward the timer IRQ to > userspace using new KVM_EXIT_IRQ return code. Timer IRQ has to be > treated

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > I mean in the device tree. Does the boot loader realize it's under a > hypervisor, and provide different device trees to the kernel? This has nothing to do with the device tree. Device tree is static. The logic sits inside Linux kernel itself: a) If we are running in HYP mode (we

Re: [RFC] Handling CP15 timer without in-kernel irqchip

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 edit

Re: [RFC] Handling CP15 timer without in-kernel irqchip

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 using physical > timer. When running under hypervisor,

Re: [RFC] Handling CP15 timer without in-kernel irqchip

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

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > I like the latter. But I guess one could even do both? You know, you are right, they absolutely do not contradict each other. Patch set for #1 is quite not big, if you are interested, and nobody votes strongly against, i can rebase it to 4.3 and post. Kind regards, Pavel Fedin

RE: [RFC] Handling CP15 timer without in-kernel irqchip

Hello! > So let me put it another way. The only way I look into this is when we > have this particular platform fully supported in mainline. I am sorry for possible misunderstanding. Please give me one more minute to defend myself... So far, we are not putting back timer disable hack. So,

Re: [RFC] Handling CP15 timer without in-kernel irqchip

On Fri, Oct 02, 2015 at 05:54:53PM +0300, Pavel Fedin wrote: > Hello! > > > So let me put it another way. The only way I look into this is when we > > have this particular platform fully supported in mainline. > > I am sorry for possible misunderstanding. Please give me one more minute to >