From mboxrd@z Thu Jan 1 00:00:00 1970 From: pbonzini@redhat.com (Paolo Bonzini) Date: Fri, 23 Sep 2016 11:19:40 +0200 Subject: [PATCH v5] KVM: arm/arm64: Route vtimer events to user space In-Reply-To: <70fc788d-f99e-4ba5-67a2-da9c1a857dfe@suse.de> References: <1474548769-195643-1-git-send-email-agraf@suse.de> <20160922212831.GD9101@cbox> <63a1e3a2-f551-017f-b6be-593b53a0b407@redhat.com> <7afbc08e-0ba2-d6fd-c1ed-e5822e05c00b@suse.de> <70fc788d-f99e-4ba5-67a2-da9c1a857dfe@suse.de> Message-ID: <71706c4a-3182-2308-8273-12aba35fccc6@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 23/09/2016 11:17, Alexander Graf wrote: >> > >> > On the other hand, what happens if you run new QEMU with old userspace? >> > With user_timer_pending you'd get an infinite stream of vmexits the >> > first time the timer fires, wouldn't you? Whereas if you keep it in the >> > kernel, userspace would simply not get the interrupt (because it doesn't >> > know about kernel_timer_pending) and think it got a spurious vmexit. >> > The kernel's IRQ would stay masked and everything would just (not) work >> > like before your patch? > Yes, we'd definitely stay more compatible by tracking it only in the > kernel. I'm not fully convinced that it's the better interface, but > since both Christoffer and you seem to choke on that part, I'll give it > a stab ;). Cool! FWIW my suggestion for kernel_timer_pending's name would be timer_irq_level (nicely matching timer->irq.level in the kernel). Paolo