On 07/06/2012 09:06 PM, Jan Kiszka wrote:
On 2012-07-06 19:16, Jan Kiszka wrote:
On 2012-06-24 16:08, Jan Kiszka wrote:
On 2012-06-24 10:49, Avi Kivity wrote:
On 06/23/2012 02:45 PM, Jan Kiszka wrote:
Hmm, we may need the iothread lock around cpu_set_apic_tpr for
!kvm_irqchip_in_kernel().
On 2012-06-24 16:08, Jan Kiszka wrote:
On 2012-06-24 10:49, Avi Kivity wrote:
On 06/23/2012 02:45 PM, Jan Kiszka wrote:
Hmm, we may need the iothread lock around cpu_set_apic_tpr for
!kvm_irqchip_in_kernel(). And as we are at it, apic_base manipulation
can be but there as well.
With
On 2012-07-06 19:16, Jan Kiszka wrote:
On 2012-06-24 16:08, Jan Kiszka wrote:
On 2012-06-24 10:49, Avi Kivity wrote:
On 06/23/2012 02:45 PM, Jan Kiszka wrote:
Hmm, we may need the iothread lock around cpu_set_apic_tpr for
!kvm_irqchip_in_kernel(). And as we are at it, apic_base manipulation
On Wed, Jun 27, 2012 at 12:19 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Jun 27, 2012 at 08:41:49AM +0100, Stefan Hajnoczi wrote:
On Wed, Jun 27, 2012 at 8:39 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Jun 26, 2012 at 8:34 PM, Marcelo Tosatti mtosa...@redhat.com
On Wed, Jun 27, 2012 at 08:41:49AM +0100, Stefan Hajnoczi wrote:
On Wed, Jun 27, 2012 at 8:39 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Jun 26, 2012 at 8:34 PM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
net.txt
On 06/26/2012 02:34 PM, Marcelo Tosatti wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM
On 06/28/2012 05:10 PM, Anthony Liguori wrote:
1. read_lock(memmap_lock)
2. MemoryRegionSection mrs = lookup(addr)
3. qom_ref(mrs.mr-dev)
4. read_unlock(memmap_lock)
5. mutex_lock(dev-lock)
6. dispatch(mrs, addr, data, size)
7. mutex_unlock(dev-lock)
Just a detail, I don't think
On Thu, Jun 28, 2012 at 09:10:39AM -0500, Anthony Liguori wrote:
1. read_lock(memmap_lock)
2. MemoryRegionSection mrs = lookup(addr)
3. qom_ref(mrs.mr-dev)
4. read_unlock(memmap_lock)
5. mutex_lock(dev-lock)
6. dispatch(mrs, addr, data, size)
7. mutex_unlock(dev-lock)
Just a
On Thu, Jun 28, 2012 at 09:10:39AM -0500, Anthony Liguori wrote:
On 06/26/2012 02:34 PM, Marcelo Tosatti wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a
On Tue, Jun 26, 2012 at 8:34 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
net.txt
iothread flow
=
1) Skip-work-if-device-locked
select(tap fd ready)
tap_send
if (trylock(TAPState-NetClientState-dev))
On Wed, Jun 27, 2012 at 8:39 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Jun 26, 2012 at 8:34 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
net.txt
iothread flow
=
1) Skip-work-if-device-locked
On 06/26/2012 10:34 PM, Marcelo Tosatti wrote:
1. read_lock(memmap_lock)
2. MemoryRegionSection mrs = lookup(addr)
3. qom_ref(mrs.mr-dev)
4. read_unlock(memmap_lock)
5. mutex_lock(dev-lock)
6. dispatch(mrs, addr, data, size)
7. mutex_unlock(dev-lock)
8.
On Wed, Jun 27, 2012 at 08:41:49AM +0100, Stefan Hajnoczi wrote:
On Wed, Jun 27, 2012 at 8:39 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Tue, Jun 26, 2012 at 8:34 PM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
net.txt
On 2012-06-26 21:34, Marcelo Tosatti wrote:
The following plan would allow progressive convertion to parallel
operation.
Jan mentioned the MMIO handler-MMIO handler deadlock in a private message.
Jan: if there is recursive MMIO accesses, you can detect that and skip
such MMIO handlers in
On Sat, Jun 23, 2012 at 11:22:07AM +0200, Jan Kiszka wrote:
On 2012-06-23 02:22, Marcelo Tosatti wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM mode. On x86, the the in-kernel irqchips has to
On 06/23/2012 02:45 PM, Jan Kiszka wrote:
Hmm, we may need the iothread lock around cpu_set_apic_tpr for
!kvm_irqchip_in_kernel(). And as we are at it, apic_base manipulation
can be but there as well.
With in-kernel irqchip, there is no such need. Also, no one accesses
eflags outside of
On Sat, Jun 23, 2012 at 7:45 PM, Jan Kiszka jan.kis...@web.de wrote:
On 2012-06-23 11:06, Marcelo Tosatti wrote:
On Fri, Jun 22, 2012 at 09:22:59PM -0300, Marcelo Tosatti wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed
On 2012-06-24 10:49, Avi Kivity wrote:
On 06/23/2012 02:45 PM, Jan Kiszka wrote:
Hmm, we may need the iothread lock around cpu_set_apic_tpr for
!kvm_irqchip_in_kernel(). And as we are at it, apic_base manipulation
can be but there as well.
With in-kernel irqchip, there is no such need.
On 2012-06-24 15:34, liu ping fan wrote:
On Sat, Jun 23, 2012 at 7:45 PM, Jan Kiszka jan.kis...@web.de wrote:
On 2012-06-23 11:06, Marcelo Tosatti wrote:
On Fri, Jun 22, 2012 at 09:22:59PM -0300, Marcelo Tosatti wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
On 2012-06-24 10:49, Avi Kivity wrote:
On 06/23/2012 02:45 PM, Jan Kiszka wrote:
Hmm, we may need the iothread lock around cpu_set_apic_tpr for
!kvm_irqchip_in_kernel(). And as we are at it, apic_base manipulation
can be but there as well.
With
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
As a first step, I will post a series later that gets rid of
kvm_flush_coalesced_mmio_buffer in the common vmexit path.
If you defer this, I can think of two places that need to flush:
- anything that accesses those memory areas (such as DMA to the
On 2012-06-24 16:35, Avi Kivity wrote:
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
As a first step, I will post a series later that gets rid of
kvm_flush_coalesced_mmio_buffer in the common vmexit path.
If you defer this, I can think of two places that need to flush:
- anything that accesses
On 06/24/2012 05:40 PM, Jan Kiszka wrote:
On 2012-06-24 16:35, Avi Kivity wrote:
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
As a first step, I will post a series later that gets rid of
kvm_flush_coalesced_mmio_buffer in the common vmexit path.
If you defer this, I can think of two places
On 2012-06-24 16:46, Avi Kivity wrote:
On 06/24/2012 05:40 PM, Jan Kiszka wrote:
On 2012-06-24 16:35, Avi Kivity wrote:
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
As a first step, I will post a series later that gets rid of
kvm_flush_coalesced_mmio_buffer in the common vmexit path.
If you
On 06/24/2012 05:51 PM, Jan Kiszka wrote:
On 2012-06-24 16:46, Avi Kivity wrote:
On 06/24/2012 05:40 PM, Jan Kiszka wrote:
On 2012-06-24 16:35, Avi Kivity wrote:
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
As a first step, I will post a series later that gets rid of
On 2012-06-24 16:56, Avi Kivity wrote:
On 06/24/2012 05:51 PM, Jan Kiszka wrote:
On 2012-06-24 16:46, Avi Kivity wrote:
On 06/24/2012 05:40 PM, Jan Kiszka wrote:
On 2012-06-24 16:35, Avi Kivity wrote:
On 06/24/2012 05:08 PM, Jan Kiszka wrote:
As a first step, I will post a series later that
On 06/24/2012 05:58 PM, Jan Kiszka wrote:
Are there really cases where the framebuffer is accessible both via MMIO
and RAM-like mappings at the same time? If so, the current flushing on
vmexit would help either as the direct mappings would not trigger exits.
Or what do you mean?
I meant
On 2012-06-23 00:59, Anthony Liguori wrote:
On 06/22/2012 05:45 PM, Jan Kiszka wrote:
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM mode. On x86, the the in-kernel irqchips has to be used because
we otherwise need to synchronize APIC and other per-cpu state
On 2012-06-23 02:22, Marcelo Tosatti wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM mode.
On Fri, Jun 22, 2012 at 09:22:59PM -0300, Marcelo Tosatti wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a possible path to get rid of the iothread
On 2012-06-23 11:06, Marcelo Tosatti wrote:
On Fri, Jun 22, 2012 at 09:22:59PM -0300, Marcelo Tosatti wrote:
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM mode. On x86, the the in-kernel irqchips has to be used because
we otherwise need to synchronize APIC and other per-cpu state accesses
that could be changed concurrently. Not yet fully analyzed is the NMI
injection
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM mode. On x86, the the in-kernel irqchips has to be used because
we otherwise need to synchronize APIC and other
On 06/22/2012 05:45 PM, Jan Kiszka wrote:
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM mode. On x86, the the in-kernel irqchips has to be used because
we otherwise need to synchronize APIC and other per-cpu state accesses
that could be changed concurrently. Not
On Sat, Jun 23, 2012 at 12:55:49AM +0200, Jan Kiszka wrote:
Should have declared this [RFC] in the subject and CC'ed kvm...
On 2012-06-23 00:45, Jan Kiszka wrote:
This sketches a possible path to get rid of the iothread lock on vmexits
in KVM mode. On x86, the the in-kernel irqchips has to
36 matches
Mail list logo
