On 01/09/2015 02:47, Linus Torvalds wrote:
> Hmm:
>
> On Fri, Aug 14, 2015 at 4:57 PM, Paolo Bonzini wrote:
>>
>> Xiao Guangrong (9):
>> KVM: MMU: fully check zero bits for sptes
>
> The above commit causes an annoying new compiler warning.
>
> The warning is bogus
On 01/09/2015 07:45, Xiao Guangrong wrote:
>
>
> Actually i triggered this warning in my another box and posted a patch
> to fix it which can be found at:
> http://lkml.iu.edu/hypermail/linux/kernel/1508.2/02771.html
> I guess Paolo is currently busy with KVM forum so the patch has not been
>
https://bugzilla.kernel.org/show_bug.cgi?id=100671
Paolo Bonzini changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, Sep 01, 2015 at 12:49:19PM +0800, Jason Wang wrote:
>
>
> On 09/01/2015 12:36 PM, Michael S. Tsirkin wrote:
> > On Tue, Sep 01, 2015 at 11:37:13AM +0800, Jason Wang wrote:
> >> >
> >> >
> >> > On 08/30/2015 05:12 PM, Michael S. Tsirkin wrote:
> >>> > > Even when we skip data decoding,
On Tue, Sep 01, 2015 at 12:47:36PM +0800, Jason Wang wrote:
>
>
> On 09/01/2015 12:31 PM, Michael S. Tsirkin wrote:
> > On Tue, Sep 01, 2015 at 11:33:43AM +0800, Jason Wang wrote:
> >>
> >> On 08/31/2015 07:33 PM, Michael S. Tsirkin wrote:
> >>> On Mon, Aug 31, 2015 at 04:03:59PM +0800, Jason
On Tue, Sep 1, 2015 at 5:29 PM, Wanpeng Li wrote:
> On 9/2/15 7:24 AM, David Matlack wrote:
>>
>> On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li wrote:
>>>
>>> Why this can happen?
>>
>> Ah, probably because I'm missing 9c8fd1ba220 (KVM: x86: optimize
On Thu, Aug 27, 2015 at 2:47 AM, Wanpeng Li wrote:
> v3 -> v4:
> * bring back grow vcpu->halt_poll_ns when interrupt arrives and shrinks
>when idle VCPU is detected
>
> v2 -> v3:
> * grow/shrink vcpu->halt_poll_ns by *halt_poll_ns_grow or
> /halt_poll_ns_shrink
> *
On 9/2/15 7:24 AM, David Matlack wrote:
On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li wrote:
On 9/2/15 6:34 AM, David Matlack wrote:
On Tue, Sep 1, 2015 at 3:30 PM, Wanpeng Li wrote:
On 9/2/15 5:45 AM, David Matlack wrote:
On Thu, Aug 27, 2015
On Tue, Sep 1, 2015 at 3:58 PM, Wanpeng Li wrote:
> On 9/2/15 6:34 AM, David Matlack wrote:
>>
>> On Tue, Sep 1, 2015 at 3:30 PM, Wanpeng Li wrote:
>>>
>>> On 9/2/15 5:45 AM, David Matlack wrote:
On Thu, Aug 27, 2015 at 2:47 AM, Wanpeng
This patchset adds a dynamic on/off switch for polling. This patchset
gets good performance on its own for both idle and Message Passing
workloads.
no-poll always-polladaptive-toggle
-
Idle
On Tue, Sep 01, 2015 at 11:41:18PM +0200, Thomas Huth wrote:
> The size of the Problem State Priority Boost Register is only
> 32 bits, so let's change the type of the corresponding variable
> accordingly to avoid future trouble.
Since we're already using lwz/stw in the assembly code in
On Tue, Sep 01, 2015 at 11:41:18PM +0200, Thomas Huth wrote:
> The size of the Problem State Priority Boost Register is only
> 32 bits, so let's change the type of the corresponding variable
> accordingly to avoid future trouble.
Since we're already using lwz/stw in the assembly code in
On Wed, 2015-09-02 at 08:24 +1000, Paul Mackerras wrote:
> On Tue, Sep 01, 2015 at 11:41:18PM +0200, Thomas Huth wrote:
> > The size of the Problem State Priority Boost Register is only
> > 32 bits, so let's change the type of the corresponding variable
> > accordingly to avoid future trouble.
>
On Wed, 2015-09-02 at 08:24 +1000, Paul Mackerras wrote:
> On Tue, Sep 01, 2015 at 11:41:18PM +0200, Thomas Huth wrote:
> > The size of the Problem State Priority Boost Register is only
> > 32 bits, so let's change the type of the corresponding variable
> > accordingly to avoid future trouble.
>
On Wed, Sep 02, 2015 at 08:25:05AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2015-09-01 at 23:41 +0200, Thomas Huth wrote:
> > The size of the Problem State Priority Boost Register is only
> > 32 bits, so let's change the type of the corresponding variable
> > accordingly to avoid future
On Wed, Sep 02, 2015 at 08:25:05AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2015-09-01 at 23:41 +0200, Thomas Huth wrote:
> > The size of the Problem State Priority Boost Register is only
> > 32 bits, so let's change the type of the corresponding variable
> > accordingly to avoid future
On Wed, 2015-09-02 at 08:45 +1000, Paul Mackerras wrote:
> On Wed, Sep 02, 2015 at 08:25:05AM +1000, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2015-09-01 at 23:41 +0200, Thomas Huth wrote:
> > > The size of the Problem State Priority Boost Register is only
> > > 32 bits, so let's change the type
On Wed, 2015-09-02 at 08:45 +1000, Paul Mackerras wrote:
> On Wed, Sep 02, 2015 at 08:25:05AM +1000, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2015-09-01 at 23:41 +0200, Thomas Huth wrote:
> > > The size of the Problem State Priority Boost Register is only
> > > 32 bits, so let's change the type
On Tue, 2015-09-01 at 23:41 +0200, Thomas Huth wrote:
> The size of the Problem State Priority Boost Register is only
> 32 bits, so let's change the type of the corresponding variable
> accordingly to avoid future trouble.
It's not future trouble, it's broken today for LE and this should fix
it
On Tue, Sep 1, 2015 at 3:30 PM, Wanpeng Li wrote:
> On 9/2/15 5:45 AM, David Matlack wrote:
>>
>> On Thu, Aug 27, 2015 at 2:47 AM, Wanpeng Li
>> wrote:
>>>
>>> v3 -> v4:
>>> * bring back grow vcpu->halt_poll_ns when interrupt arrives and shrinks
On 9/2/15 6:34 AM, David Matlack wrote:
On Tue, Sep 1, 2015 at 3:30 PM, Wanpeng Li wrote:
On 9/2/15 5:45 AM, David Matlack wrote:
On Thu, Aug 27, 2015 at 2:47 AM, Wanpeng Li
wrote:
v3 -> v4:
* bring back grow vcpu->halt_poll_ns when
This patch removes almost all of the overhead of polling for idle VCPUs
by disabling polling for long halts. The length of the previous halt
is used as a predictor for the current halt:
if (length of previous halt < halt_poll_ns): poll for halt_poll_ns
else: don't poll
This tends to work
From: Wanpeng Li
Change halt_poll_ns into per-VCPU variable, seeded from module parameter,
to allow greater flexibility.
Signed-off-by: Wanpeng Li
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 5 +++--
2 files changed, 4
The size of the Problem State Priority Boost Register is only
32 bits, so let's change the type of the corresponding variable
accordingly to avoid future trouble.
Signed-off-by: Thomas Huth
---
arch/powerpc/include/asm/kvm_host.h | 2 +-
1 file changed, 1 insertion(+), 1
The size of the Problem State Priority Boost Register is only
32 bits, so let's change the type of the corresponding variable
accordingly to avoid future trouble.
Signed-off-by: Thomas Huth
---
arch/powerpc/include/asm/kvm_host.h | 2 +-
1 file changed, 1 insertion(+), 1
On 09/02/2015 01:03 AM, Paolo Bonzini wrote:
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index fb16a8ea3dee..3c745f3abde8 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3309,13 +3309,13 @@ walk_shadow_page_get_mmio_spte(struct kvm_vcpu *vcpu,
u64 addr, u64 *sptep)
On 09/01/2015 09:56 PM, Markus Trippelsdorf wrote:
On 2015.09.01 at 21:00 +0800, Xiao Guangrong wrote:
Did it trigger the BUG()/BUG_ON() in mtrr2protval()/fallback_mtrr_type()?
If yes, could you please print the actual value out?
It is the BUG() in fallback_mtrr_type(). I changed it to a
On Tue, 2015-09-01 at 23:41 +0200, Thomas Huth wrote:
> The size of the Problem State Priority Boost Register is only
> 32 bits, so let's change the type of the corresponding variable
> accordingly to avoid future trouble.
It's not future trouble, it's broken today for LE and this should fix
it
On 9/2/15 5:45 AM, David Matlack wrote:
On Thu, Aug 27, 2015 at 2:47 AM, Wanpeng Li wrote:
v3 -> v4:
* bring back grow vcpu->halt_poll_ns when interrupt arrives and shrinks
when idle VCPU is detected
v2 -> v3:
* grow/shrink vcpu->halt_poll_ns by
On Tue, Sep 01, 2015 at 04:22:22PM +0800, Jason Wang wrote:
>
>
> On 09/01/2015 02:54 PM, Michael S. Tsirkin wrote:
> > On Tue, Sep 01, 2015 at 12:47:36PM +0800, Jason Wang wrote:
> >>
> >> On 09/01/2015 12:31 PM, Michael S. Tsirkin wrote:
> >>> On Tue, Sep 01, 2015 at 11:33:43AM +0800, Jason
On 2015.09.01 at 10:56 +0200, Ingo Molnar wrote:
>
> * Markus Trippelsdorf wrote:
> > As I wrote in my other reply. The boot failure is nondeterministic (boot
> > succeeds roughly every sixth time). So the bisection and the patch is
> > just bogus (,but the boot failure
On Mon, Aug 31, 2015 at 02:51:50PM +0800, Xiao Guangrong wrote:
>
>
> On 08/28/2015 08:01 PM, Stefan Hajnoczi wrote:
> >On Wed, Aug 26, 2015 at 06:46:35PM +0800, Xiao Guangrong wrote:
> >>On 08/26/2015 12:23 AM, Stefan Hajnoczi wrote:
> >>>On Fri, Aug 14, 2015 at 10:52:07PM +0800, Xiao Guangrong
https://bugzilla.kernel.org/show_bug.cgi?id=103851
Bug ID: 103851
Summary: qemu windows guest hangs on 100% cpu usage
Product: Virtualization
Version: unspecified
Kernel Version: 3.13.6
Hardware: Intel
OS: Linux
On Mon, Aug 31, 2015 at 02:23:43PM +0800, Xiao Guangrong wrote:
>
> Hi Stefan,
>
> On 08/28/2015 07:58 PM, Stefan Hajnoczi wrote:
>
> >
> +goto do_unmap;
> +}
> +
> +nvdimm->device_index = new_device_index();
> +sprintf(name, "NVDIMM-%d",
On 09/01/2015 02:54 PM, Michael S. Tsirkin wrote:
> On Tue, Sep 01, 2015 at 12:47:36PM +0800, Jason Wang wrote:
>>
>> On 09/01/2015 12:31 PM, Michael S. Tsirkin wrote:
>>> On Tue, Sep 01, 2015 at 11:33:43AM +0800, Jason Wang wrote:
On 08/31/2015 07:33 PM, Michael S. Tsirkin wrote:
> On
https://bugzilla.kernel.org/show_bug.cgi?id=103851
Wanpeng Li changed:
What|Removed |Added
CC|
On 2015.09.02 at 06:31 +0800, Xiao Guangrong wrote:
>
>
> On 09/01/2015 09:56 PM, Markus Trippelsdorf wrote:
> > On 2015.09.01 at 21:00 +0800, Xiao Guangrong wrote:
> >>
> >> Did it trigger the BUG()/BUG_ON() in mtrr2protval()/fallback_mtrr_type()?
> >> If yes, could you please print the actual
On 1 September 2015 at 14:52, Andre Przywara wrote:
> Also the GIC specification says that everything must be accessible with
> 32-bit accesses. Correct me if I am wrong on this, but vCPUs are not
> supposed to run while you are getting/setting VGIC registers, right? So
>
On 09/01/2015 06:04 PM, Markus Trippelsdorf wrote:
On 2015.09.01 at 10:56 +0200, Ingo Molnar wrote:
* Markus Trippelsdorf wrote:
As I wrote in my other reply. The boot failure is nondeterministic (boot
succeeds roughly every sixth time). So the bisection and the
Hello!
> Have you thought about proper locking/serializing of access to the GIC
> state in these accessor functions?
I am in the process of rewriting the whole thing, and i came to this point.
What kind of locking would you expect ? It's a CPU interface, it does not
affect state of any
On 2015.09.01 at 21:00 +0800, Xiao Guangrong wrote:
>
> Did it trigger the BUG()/BUG_ON() in mtrr2protval()/fallback_mtrr_type()?
> If yes, could you please print the actual value out?
It is the BUG() in fallback_mtrr_type(). I changed it to a printk and
it prints 1 for the value of mtrr.
Hello!
> I agree on this, actually I consider this dangerous. Currently the
> memory behind addr in QEMU (hw/intc/arm_gic_kvm.c:kvm_arm_gic_get() for
> instance) is only uint32_t, so you have to take care to provide uint64_t
> backing for those registers, which means that there must be a match
>
On Tue, Sep 01, 2015 at 04:09:18PM +0300, Pavel Fedin wrote:
> Hello!
>
> > Have you thought about proper locking/serializing of access to the GIC
> > state in these accessor functions?
>
> I am in the process of rewriting the whole thing, and i came to this point.
> What kind of locking
Hi Pavel,
...
>> diff --git a/virt/kvm/arm/vgic-v3-emul.c b/virt/kvm/arm/vgic-v3-emul.c
>> index e661e7f..b3847e1 100644
>> --- a/virt/kvm/arm/vgic-v3-emul.c
>> +++ b/virt/kvm/arm/vgic-v3-emul.c
...
>> @@ -1000,40 +1102,95 @@ static void vgic_v3_destroy(struct kvm_device *dev)
>>
subscribe kvm
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
45 matches
Mail list logo