On 04/06/12 03:57, Rusty Russell wrote:
> Unfortunately, this conflicts with Asias He's deadlock fix, which has
> us just using the block-layer-supplied spinlock.
>
> If we drop the lock around the kick as you suggest, we're playing with
> fire. All the virtio backends have an atomic notify, so t
On 05/22/2012 12:37 AM, Avi Kivity wrote:
Please pull from:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
Pulled. Thanks.
Regards,
Anthony Liguori
This is mostly Jan's MSI for KVM patches.
Avi Kivity (1):
On Mon, Jun 04, 2012 at 11:27:39AM +0930, Rusty Russell wrote:
> On Wed, 30 May 2012 15:39:05 +0200, Christian Borntraeger
> wrote:
> > On 30/05/12 15:19, Stefan Hajnoczi wrote:
> > > Holding the vblk->lock across kick causes poor scalability in SMP
> > > guests. If one CPU is doing virtqueue ki
The patch adds guest code for msr between guest and hypervisor. The
msr will export the vcpu running/pre-empted information to the guest
from host. This will enable guest to intelligently send ipi to running
vcpus and set flag for pre-empted vcpus. This will prevent waiting for
vcpus that are not r
From: Peter Zijlstra
get_user_pages_fast() depends on the IPI to hold off page table
teardown while they are locklessly walked with interrupts disabled.
If a vcpu were to be preempted while in this critical section, another
vcpu tearing down page tables would go ahead and destroy them. when
the
From: Nikunj A. Dadhania
Certain architecture(viz. x86, arm, s390) have hardware page-table
walkers(#PF). So during the RCU page-table teardown process make sure
we do a tlb flush of page-table pages on all relevant CPUs to
synchronize against hardware walkers, and then free the pages.
Moreover,
In place of looping continuously introduce a halt if we do not succeed
after some time.
For vcpus that were running an IPI is sent. In case, it went to sleep
between this, we will be doing flush_on_enter(harmless). But as a
flush IPI was already sent, that will be processed in ipi handler,
this m
Signed-off-by: Nikunj A. Dadhania
---
arch/x86/include/asm/kvm_para.h |4
arch/x86/kernel/kvm.c | 18 +-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 684a285..651a305 1
flush_tlb_others_ipi depends on lot of statics in tlb.c. Replicated
the flush_tlb_others_ipi as kvm_flush_tlb_others to further adapt to
paravirtualization.
Use the vcpu state information inside the kvm_flush_tlb_others to
avoid sending ipi to pre-empted vcpus.
* Do not send ipi's to offline vcp
Hypervisor code to indicate guest running/pre-empteded status through
msr.
Suggested-by: Peter Zijlstra
Signed-off-by: Nikunj A. Dadhania
---
arch/x86/include/asm/kvm_host.h |7 ++
arch/x86/kvm/cpuid.c|1 +
arch/x86/kvm/x86.c | 45 +
Remote flushing api's does a busy wait which is fine in bare-metal
scenario. But with-in the guest, the vcpus might have been pre-empted
or blocked. In this scenario, the initator vcpu would end up
busy-waiting for a long amount of time.
This was discovered in our gang scheduling test and other w
On 05/25/2012 08:53 PM, Luiz Capitulino wrote:
On Fri, 25 May 2012 13:01:37 +0100
Stefan Hajnoczi wrote:
I agree it would be nice to drop entirely but I don't feel happy doing
that to users who might have QEMU buried in scripts somewhere. One
day they upgrade packages and suddenly their stuff
On Wed, 30 May 2012 15:39:05 +0200, Christian Borntraeger
wrote:
> On 30/05/12 15:19, Stefan Hajnoczi wrote:
> > Holding the vblk->lock across kick causes poor scalability in SMP
> > guests. If one CPU is doing virtqueue kick and another CPU touches the
> > vblk->lock it will have to spin until
On Fri, 25 May 2012 10:34:46 +0800, Asias He wrote:
> This patch set fixes the race when hot-unplug stressed disk.
>
> Asias He (3):
> virtio-blk: Call del_gendisk() before disable guest kick
> virtio-blk: Reset device after blk_cleanup_queue()
> virtio-blk: Use block layer provided spinloc
On 05/29/2012 04:14 PM, Markus Armbruster wrote:
Luiz Capitulino writes:
On Mon, 28 May 2012 12:17:04 +0100
Stefan Hajnoczi wrote:
What we need to decide is whether it's okay to drop QEMU "VLANs"
completely and change dump command-line syntax?
I'd vote for dropping it.
I think vlan-hub
On 05/31/2012 12:46 PM, H. Peter Anvin wrote:
> On 05/31/2012 01:01 AM, Raghavendra K T wrote:
>> +
>> +TODO:
>> +1. more information on input and output needed?
>> +2. Add more detail to purpose of hypercalls.
>>
>
> 1. definitely, including the hypercall ABI.
>
> -hpa
>
I was wondering
On Fri, Jun 1, 2012 at 8:04 PM, Marcelo Tosatti wrote:
> On Fri, May 25, 2012 at 12:22:59PM -0400, Christoffer Dall wrote:
>> Introduces a couple of print functions, which are essentially wrappers
>> around standard printk functions, with a KVM: prefix.
>>
>> Functions introduced or modified are:
Introduces a couple of print functions, which are essentially wrappers
around standard printk functions, with a KVM: prefix.
Functions introduced or modified are:
- kvm_err(fmt, ...)
- kvm_info(fmt, ...)
- kvm_debug(fmt, ...)
- kvm_pr_unimpl(fmt, ...)
- pr_unimpl(vcpu, fmt, ...) -> vcpu_unimp
On 03.06.2012 15:43, Avi Kivity wrote:
> On 06/03/2012 04:01 PM, Johannes Bauer wrote:
>> On 03.06.2012 14:33, Avi Kivity wrote:
>>
when trying to install Windows7 in a qemu-kvm 1.0.1 installation on
Gentoo on my host running
>>>
>>> Is that a 32-bit or 64-bit Windows 7?
>>
>> 64 bit. But
On 06/03/2012 04:01 PM, Johannes Bauer wrote:
> On 03.06.2012 14:33, Avi Kivity wrote:
>
>>> when trying to install Windows7 in a qemu-kvm 1.0.1 installation on
>>> Gentoo on my host running
>>
>> Is that a 32-bit or 64-bit Windows 7?
>
> 64 bit. But I've also (in despair) tried installing 32 Bi
On 03.06.2012 14:33, Avi Kivity wrote:
> You can run vmxcap [1] and see.
Ah, I forgot to attach the output of vmxcap, which might be of interest.
First the host where it does not work:
pin-based controls
External interrupt exiting yes
NMI exiting ye
On 03.06.2012 14:33, Avi Kivity wrote:
>> when trying to install Windows7 in a qemu-kvm 1.0.1 installation on
>> Gentoo on my host running
>
> Is that a 32-bit or 64-bit Windows 7?
64 bit. But I've also (in despair) tried installing 32 Bit Windows 7,
with the exact same effect.
>> EAX=0010
On 06/03/2012 03:18 PM, Johannes Bauer wrote:
> Hi list,
>
> when trying to install Windows7 in a qemu-kvm 1.0.1 installation on
> Gentoo on my host running
Is that a 32-bit or 64-bit Windows 7?
>
> Linux joequad 3.3.7 #1 SMP PREEMPT Sun Jun 3 12:05:59 CEST 2012 x86_64
> Intel(R) Core(TM)2 Quad
Hi list,
when trying to install Windows7 in a qemu-kvm 1.0.1 installation on
Gentoo on my host running
Linux joequad 3.3.7 #1 SMP PREEMPT Sun Jun 3 12:05:59 CEST 2012 x86_64
Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux
with a host CPU of
processor : 0
vendor_id
On 06/01/2012 09:26 PM, Jan Kiszka wrote:
>
>> you suggesting we need a request_edge_threaded_only_irq() API? Thanks,
>
> I'm just wondering if that restriction for threaded IRQs is really
> necessary for all use cases we have. Threaded MSIs do not appear to me
> like have to be handled that con
I see this in 3.5-rc1:
arch/x86/kvm/mmu.c: In function ‘kvm_test_age_rmapp’:
arch/x86/kvm/mmu.c:1271: warning: ‘iter.desc’ may be used uninitialized in this
function
The line in question was introduced by commit
1e3f42f03c38c29c1814199a6f0a2f01b919ea3f
static int kvm_test_age_rmapp(struct kvm
Implementation of PV EOI using shared memory.
This reduces the number of exits an interrupt
causes as much as by half.
The idea is simple: there's a bit, per APIC, in guest memory,
that tells the guest that it does not need EOI.
We set it before injecting an interrupt and clear
before injecting a
Commit eb0dc6d0368072236dcd086d7fdc17fd3c4574d4 introduced apic
attention bitmask but kvm still syncs lapic unconditionally.
As that commit suggested and in anticipation of adding more attention
bits, only sync lapic if(apic_attention).
Signed-off-by: Michael S. Tsirkin
---
arch/x86/kvm/x86.c |
Document the new EOI MSR. Couldn't decide whether this change belongs
conceptually on guest or host side, so a separate patch.
Signed-off-by: Michael S. Tsirkin
---
Documentation/virtual/kvm/msr.txt | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff
__test_and_clear_bit is actually atomic with respect
to the local CPU. Add a note saying that KVM on x86
relies on this behaviour so people don't accidentaly break it.
Also warn not to rely on this in portable code.
Signed-off-by: Michael S. Tsirkin
---
arch/x86/include/asm/bitops.h |7 +
The idea is simple: there's a bit, per APIC, in guest memory,
that tells the guest that it does not need EOI.
Guest tests it using a single est and clear operation - this is
necessary so that host can detect interrupt nesting - and if set, it can
skip the EOI MSR.
I run a simple microbenchmark to
The logic in find_highest_vector looks
strange until you realize the reason for the
weird memory layout, which is because this is
what the CPU microcode expects.
Add a comment so this stops tripping people up.
Signed-off-by: Michael S. Tsirkin
---
arch/x86/kvm/lapic.h |5 +
1 files chan
Each time we need to cancel injection we invoke same code
(cancel_injection callback). Move it towards the end of function using
the familiar goto on error pattern.
Will make it easier to do more cleanups for PV EOI.
Signed-off-by: Michael S. Tsirkin
---
arch/x86/kvm/x86.c | 10 ++
1
I'm looking at reducing the interrupt overhead for virtualized guests:
some workloads spend a large part of their time processing interrupts.
On kvm, an EOI write from the guest causes an expensive exit to host; we
avoid this using shared memory.
The patches work fine on my boxes. See individual
We perform ISR lookups twice: during interrupt
injection and on EOI. Typical workloads only have
a single bit set there. So we can avoid ISR scans by
1. counting bits as we set/clear them in ISR
2. on set, caching the injected vector number
3. on clear, invalidating the cache
The real purpose of t
35 matches
Mail list logo