On Mon, Feb 25, 2013 at 09:01:02PM +0200, Gleb Natapov wrote:
On Mon, Feb 25, 2013 at 08:56:07PM +0200, Avi Kivity wrote:
On Mon, Feb 25, 2013 at 7:43 PM, Gleb Natapov g...@redhat.com wrote:
3. Do not report KVM_IRQ_LINE_STATUS capability and move RTC to use EOI
notifiers for
On Tue, Feb 26, 2013 at 10:12 AM, Gleb Natapov g...@redhat.com wrote:
But do not see how to implement efficiently without interface change. The
idea is basically to register ACK notifier for RTC interrupt but terminate
it in the kernel instead of reporting to userspace. Kernel should know
Avi Kivity wrote on 2013-02-25:
I didn't really follow, but is the root cause the need to keep track
of interrupt coalescing? If so we can recommend that users use
KVM_IRQ_LINE when coalescing is unneeded, and move interrupt injection
with irq coalescing support to vcpu context.
So we can
On Mon, Feb 25, 2013 at 08:42:52AM +, Zhang, Yang Z wrote:
Avi Kivity wrote on 2013-02-25:
I didn't really follow, but is the root cause the need to keep track
of interrupt coalescing? If so we can recommend that users use
KVM_IRQ_LINE when coalescing is unneeded, and move interrupt
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 08:42:52AM +, Zhang, Yang Z wrote:
Avi Kivity wrote on 2013-02-25:
I didn't really follow, but is the root cause the need to keep track
of interrupt coalescing? If so we can recommend that users use
KVM_IRQ_LINE when coalescing is
On Mon, Feb 25, 2013 at 11:04:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 08:42:52AM +, Zhang, Yang Z wrote:
Avi Kivity wrote on 2013-02-25:
I didn't really follow, but is the root cause the need to keep track
of interrupt coalescing? If
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 11:04:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 08:42:52AM +, Zhang, Yang Z wrote:
Avi Kivity wrote on 2013-02-25:
I didn't really follow, but is the root cause the need to keep
On Mon, Feb 25, 2013 at 11:13:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 11:04:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 08:42:52AM +, Zhang, Yang Z wrote:
Avi Kivity wrote on 2013-02-25:
Marcelo Tosatti wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 11:13:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 11:04:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 08:42:52AM +, Zhang, Yang Z wrote:
On Mon, Feb 25, 2013 at 11:13:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 11:04:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 08:42:52AM +, Zhang, Yang Z wrote:
Avi Kivity wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 06:55:58AM +, Zhang, Yang Z wrote:
p1)
cpu0 cpu1vcpu0
test_and_set_bit(PIR-A)
set KVM_REQ_EVENT
process REQ_EVENT
On Mon, Feb 25, 2013 at 03:34:19PM +0200, Gleb Natapov wrote:
On Mon, Feb 25, 2013 at 11:13:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 11:04:25AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-25:
On Mon, Feb 25, 2013 at
On Mon, Feb 25, 2013 at 11:00:21AM -0300, Marcelo Tosatti wrote:
I see a couple of possible solutions:
1. Do what Avi said. Make KVM_IRQ_LINE_STATUS be synchronous. Cons:
current QEMU uses KVM_IRQ_LINE_STATUS always and it means that it
will be slow on newer kernels
Can add a capability
Marcelo Tosatti wrote on 2013-02-25:
On Mon, Feb 25, 2013 at 06:55:58AM +, Zhang, Yang Z wrote:
p1)
cpu0 cpu1vcpu0
test_and_set_bit(PIR-A)
set KVM_REQ_EVENT
process REQ_EVENT
I see a couple of possible solutions:
1. Do what Avi said. Make KVM_IRQ_LINE_STATUS be synchronous. Cons:
current QEMU uses KVM_IRQ_LINE_STATUS always and it means that it
will be slow on newer kernels
You could backport the qemu change, verify that it builds, and push it
to stable branches.
On Mon, Feb 25, 2013 at 11:17:39AM -0300, Marcelo Tosatti wrote:
On Mon, Feb 25, 2013 at 11:00:21AM -0300, Marcelo Tosatti wrote:
I see a couple of possible solutions:
1. Do what Avi said. Make KVM_IRQ_LINE_STATUS be synchronous. Cons:
current QEMU uses KVM_IRQ_LINE_STATUS always and it
On Mon, Feb 25, 2013 at 06:50:40PM +0200, Avi Kivity wrote:
I see a couple of possible solutions:
1. Do what Avi said. Make KVM_IRQ_LINE_STATUS be synchronous. Cons:
current QEMU uses KVM_IRQ_LINE_STATUS always and it means that it
will be slow on newer kernels
You could backport the
On Mon, Feb 25, 2013 at 7:43 PM, Gleb Natapov g...@redhat.com wrote:
3. Do not report KVM_IRQ_LINE_STATUS capability and move RTC to use EOI
notifiers for interrupt reinjection. This requires us to add interface
for reporting EOI to userspace. This is not in the scope of this
patchset.
On Mon, Feb 25, 2013 at 08:56:07PM +0200, Avi Kivity wrote:
On Mon, Feb 25, 2013 at 7:43 PM, Gleb Natapov g...@redhat.com wrote:
3. Do not report KVM_IRQ_LINE_STATUS capability and move RTC to use EOI
notifiers for interrupt reinjection. This requires us to add interface
for reporting
On Mon, Feb 25, 2013 at 07:40:07PM +0200, Gleb Natapov wrote:
On Mon, Feb 25, 2013 at 11:17:39AM -0300, Marcelo Tosatti wrote:
On Mon, Feb 25, 2013 at 11:00:21AM -0300, Marcelo Tosatti wrote:
I see a couple of possible solutions:
1. Do what Avi said. Make KVM_IRQ_LINE_STATUS be
Marcelo Tosatti wrote on 2013-02-24:
On Sat, Feb 23, 2013 at 03:16:11PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
On Fri, Feb 22, 2013 at 09:42:32PM +0800, Yang Zhang
Gleb Natapov wrote on 2013-02-24:
On Sat, Feb 23, 2013 at 02:05:13PM -0300, Marcelo Tosatti wrote:
On Sat, Feb 23, 2013 at 05:31:44PM +0200, Gleb Natapov wrote:
On Sat, Feb 23, 2013 at 11:48:54AM -0300, Marcelo Tosatti wrote:
1. orig_irr = read irr from vapic page
2. if (orig_irr != 0)
3.
On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
I do not think it fixes it. There is no guaranty that IPI will be
processed by remote cpu while sending cpu is still in locked section, so
the same race may happen regardless. As you say above there are 3
contexts, but only two
Gleb Natapov wrote on 2013-02-24:
On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
I do not think it fixes it. There is no guaranty that IPI will be
processed by remote cpu while sending cpu is still in locked section, so
the same race may happen regardless. As you say above
On Sun, Feb 24, 2013 at 02:26:36PM +, Zhang, Yang Z wrote:
I do not see where those assumptions are coming from. Testing pir does
not guaranty that the IPI is not processed by VCPU right now.
iothread: vcpu:
send_irq()
lock(pir)
check pir and irr
set
On Sun, Feb 24, 2013 at 01:17:59PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-24:
On Sat, Feb 23, 2013 at 03:16:11PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on
On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
contexts, but only two use locks.
See following logic, I think the problem you mentioned will not happened with
current logic.
get lock
if test_pir (this will ensure there is no in flight IPI for same interrupt.
Since we are
On Sun, Feb 24, 2013 at 04:19:17PM +0200, Gleb Natapov wrote:
On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
I do not think it fixes it. There is no guaranty that IPI will be
processed by remote cpu while sending cpu is still in locked section, so
the same race may happen
I didn't really follow, but is the root cause the need to keep track
of interrupt coalescing? If so we can recommend that users use
KVM_IRQ_LINE when coalescing is unneeded, and move interrupt injection
with irq coalescing support to vcpu context.
It's not pleasant to cause a performance
Marcelo Tosatti wrote on 2013-02-25:
On Sun, Feb 24, 2013 at 01:17:59PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-24:
On Sat, Feb 23, 2013 at 03:16:11PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z
Marcelo Tosatti wrote on 2013-02-25:
On Sun, Feb 24, 2013 at 01:55:07PM +, Zhang, Yang Z wrote:
contexts, but only two use locks.
See following logic, I think the problem you mentioned will not
happened with current logic.
get lock
if test_pir (this will ensure there is no in flight
On Fri, Feb 22, 2013 at 09:42:32PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
Posted Interrupt allows APIC interrupts to inject into guest directly
without any vmexit.
- When delivering a interrupt to guest, if target vcpu is running,
update Posted-interrupt
Marcelo Tosatti wrote on 2013-02-23:
On Fri, Feb 22, 2013 at 09:42:32PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
Posted Interrupt allows APIC interrupts to inject into guest directly
without any vmexit.
- When delivering a interrupt to guest, if target vcpu is
On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
+ return test_bit(vector, (unsigned long *)pi_desc-pir);
+}
+
+static void pi_set_pir(int vector, struct pi_desc *pi_desc)
+{
+ __set_bit(vector, (unsigned long *)pi_desc-pir);
+}
This must be locked atomic
On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
On Fri, Feb 22, 2013 at 09:42:32PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
Posted Interrupt allows APIC interrupts to inject into guest directly
without any
On Sat, Feb 23, 2013 at 04:35:30PM +0200, Gleb Natapov wrote:
On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
+return test_bit(vector, (unsigned long *)pi_desc-pir);
+}
+
+static void pi_set_pir(int vector, struct pi_desc *pi_desc)
+{
+
Marcelo Tosatti wrote on 2013-02-23:
On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
On Fri, Feb 22, 2013 at 09:42:32PM +0800, Yang Zhang wrote:
From: Yang Zhang yang.z.zh...@intel.com
Posted Interrupt allows APIC interrupts to inject
On Sat, Feb 23, 2013 at 11:48:54AM -0300, Marcelo Tosatti wrote:
1. orig_irr = read irr from vapic page
2. if (orig_irr != 0)
3. return false;
4. kvm_make_request(KVM_REQ_EVENT)
5. bool injected = !test_and_set_bit(PIR)
6. if (vcpu-guest_mode injected)
7. if
On Sat, Feb 23, 2013 at 05:31:44PM +0200, Gleb Natapov wrote:
On Sat, Feb 23, 2013 at 11:48:54AM -0300, Marcelo Tosatti wrote:
1. orig_irr = read irr from vapic page
2. if (orig_irr != 0)
3.return false;
4. kvm_make_request(KVM_REQ_EVENT)
5. bool injected =
On Sat, Feb 23, 2013 at 03:16:11PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
On Sat, Feb 23, 2013 at 02:05:28PM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-23:
On Fri, Feb 22, 2013 at 09:42:32PM +0800, Yang Zhang wrote:
From: Yang Zhang
On Sat, Feb 23, 2013 at 02:05:13PM -0300, Marcelo Tosatti wrote:
On Sat, Feb 23, 2013 at 05:31:44PM +0200, Gleb Natapov wrote:
On Sat, Feb 23, 2013 at 11:48:54AM -0300, Marcelo Tosatti wrote:
1. orig_irr = read irr from vapic page
2. if (orig_irr != 0)
3. return false;
On Sat, Feb 23, 2013 at 09:42:14PM +0200, Gleb Natapov wrote:
explanation why its believed to be benign (given how the injection
return value is interpreted) could also work. Its ugly, though... murphy
is around.
The race above is not benign. It will report interrupt as coalesced
while in
On Sat, Feb 23, 2013 at 04:52:59PM -0300, Marcelo Tosatti wrote:
OTOH spinlock is not the end of the world, can figure out something later
(we've tried without success so far).
It serializes all injections into vcpu. I do not believe now that even
with lock we are safe for the reason I
43 matches
Mail list logo
