On Wed, 13 Mar 2013 13:06:23 +0800
Xiao Guangrong wrote:
> On 03/12/2013 04:44 PM, Takuya Yoshikawa wrote:
> > This will be used not to zap unrelated mmu pages when creating/moving
> > a memory slot later.
>
> How about save all mmio spte into a mmio-rmap?
The problem is that other mmu code wou
Changes in v2
- Use vq->private_data insteadof vs->vs_endpoint
- Add label in vhost_scsi_clear_endpoint to simply unlock code.
Asias He (3):
tcm_vhost: Add missed lock in vhost_scsi_clear_endpoint()
tcm_vhost: Flush vhost_work in vhost_scsi_flush()
tcm_vhost: Use vq->private_data to indica
tv_tpg->tv_tpg_vhost_count should be protected by tv_tpg->tv_tpg_mutex.
Signed-off-by: Asias He
Reviewed-by: Stefan Hajnoczi
---
drivers/vhost/tcm_vhost.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index
We also need to flush the vhost_works. It is the completion vhost_work
currently.
Signed-off-by: Asias He
Reviewed-by: Stefan Hajnoczi
---
drivers/vhost/tcm_vhost.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhost.c
index 79d3aea..43fb11e 1
Currently, vs->vs_endpoint is used indicate if the endpoint is setup or
not. It is set or cleared in vhost_scsi_set_endpoint() or
vhost_scsi_clear_endpoint() under the vs->dev.mutex lock. However, when
we check it in vhost_scsi_handle_vq(), we ignored the lock, this is
wrong.
Instead of using the
On 2013-03-12 13:06, Paolo Bonzini wrote:
>> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>> index 02b51dd..4a21a6b 100644
>> --- a/arch/x86/kvm/lapic.c
>> +++ b/arch/x86/kvm/lapic.c
>> @@ -731,7 +731,7 @@ static int __apic_accept_irq(struct kvm_lapic *apic, int
>> delivery_mode,
>>
On 03/13/2013 03:28 PM, Takuya Yoshikawa wrote:
> On Wed, 13 Mar 2013 13:06:23 +0800
> Xiao Guangrong wrote:
>
>> On 03/12/2013 04:44 PM, Takuya Yoshikawa wrote:
>>> This will be used not to zap unrelated mmu pages when creating/moving
>>> a memory slot later.
>>
>> How about save all mmio spte i
On 12/03/13 22:07, Christopher Covington wrote:
Hi Christopher,
> On 03/12/2013 02:05 PM, Marc Zyngier wrote:
>> On 12/03/13 17:31, Christopher Covington wrote:
>>> Hi Marc,
>>>
>>> On 03/04/2013 10:47 PM, Marc Zyngier wrote:
Let userspace play with the guest registers.
Signed-off-
Il 13/03/2013 04:02, Asias He ha scritto:
> On Tue, Mar 12, 2013 at 09:26:18AM +0100, Paolo Bonzini wrote:
>> Il 12/03/2013 03:42, Asias He ha scritto:
>>> This helper is useful to check if vs->vs_endpoint is setup by
>>> vhost_scsi_set_endpoint()
>>>
>>> Signed-off-by: Asias He
>>> Reviewed-by: S
Il 13/03/2013 04:13, Asias He ha scritto:
>> > This takes dev mutex on data path which will introduce
>> > contention esp for multiqueue.
> Yes, for now it is okay, but for concurrent execution of multiqueue it is
> really bad.
>
> By the way, what is the overhead of taking and releasing the
> vs-
Il 12/03/2013 10:55, Michael S. Tsirkin ha scritto:
> > Why? Why should qemu prevent from improving the driver and the benefit
> > to the other user of the driver? Kvm tool is already using it since last
> > Aug. This adds the missing disk hotplug support to kvm tool.
>
> Basically we shouldn't ad
A VCPU sending INIT or SIPI to some other VCPU races for setting the
remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
was overwritten by kvm_emulate_halt and, thus, got lost.
This introduces APIC events for those two signals, keeping them in
kvm_apic until kvm_apic_accept_e
Il 13/03/2013 08:34, Asias He ha scritto:
> Currently, vs->vs_endpoint is used indicate if the endpoint is setup or
> not. It is set or cleared in vhost_scsi_set_endpoint() or
> vhost_scsi_clear_endpoint() under the vs->dev.mutex lock. However, when
> we check it in vhost_scsi_handle_vq(), we ignor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 13/03/2013 08:39, Jan Kiszka ha scritto:
>> I think this should clear pending SIPIs, unless KVM_APIC_INIT
>> was already set in which case it should be a no-op. Something
>> like:
>>
>> e = apic->pending_events; while (!(e & KVM_APIC_INIT)) e =
>>
On 2013-03-13 10:03, Paolo Bonzini wrote:
> Il 13/03/2013 08:39, Jan Kiszka ha scritto:
>>> I think this should clear pending SIPIs, unless KVM_APIC_INIT
>>> was already set in which case it should be a no-op. Something
>>> like:
>>>
>>> e = apic->pending_events; while (!(e & KVM_APIC_INIT)) e =
>
On Tue, Mar 12, 2013 at 10:36:43PM -0300, Marcelo Tosatti wrote:
>
> As noticed by Ulrich Obergfell , the mmu
> counters are for beancounting purposes only - so n_used_mmu_pages and
> n_max_mmu_pages could be relaxed (example: before f0f5933a1626c8df7b),
> resulting in n_used_mmu_pages > n_max_mmu
Only interrupt and NMI exiting are mandatory for KVM to work, thus can
be exposed to the guest unconditionally, virtual NMI exiting is
optional. So we must not advertise it unless the host supports it.
Introduce the symbolic constant PIN_BASED_ALWAYSON_WITHOUT_TRUE_MSR at
this chance.
Signed-off-
Provided the host has this feature, it's straightforward to offer it to
the guest as well. We just need to load to timer value on L2 entry if
the feature was enabled by L1 and watch out for the corresponding exit
reason.
Signed-off-by: Jan Kiszka
---
arch/x86/include/asm/vmx.h |3 +++
a
On Wed, Mar 13, 2013 at 09:50:55AM +0100, Jan Kiszka wrote:
> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
> was overwritten by kvm_emulate_halt and, thus, got lost.
>
> This introduces APIC events f
Il 13/03/2013 09:50, Jan Kiszka ha scritto:
> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
> was overwritten by kvm_emulate_halt and, thus, got lost.
>
> This introduces APIC events for those two sig
On 2013-03-13 11:31, Gleb Natapov wrote:
> On Wed, Mar 13, 2013 at 09:50:55AM +0100, Jan Kiszka wrote:
>> A VCPU sending INIT or SIPI to some other VCPU races for setting the
>> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
>> was overwritten by kvm_emulate_halt and, thus
On 2013-03-13 12:10, Paolo Bonzini wrote:
> Il 13/03/2013 09:50, Jan Kiszka ha scritto:
>> A VCPU sending INIT or SIPI to some other VCPU races for setting the
>> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
>> was overwritten by kvm_emulate_halt and, thus, got lost.
>>
On 2013-03-13 12:16, Jan Kiszka wrote:
>>> @@ -5871,8 +5867,8 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
>>> srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx);
>>> kvm_vcpu_block(vcpu);
>>> vcpu->srcu_idx = srcu_read_lock(&kvm->srcu)
A VCPU sending INIT or SIPI to some other VCPU races for setting the
remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
was overwritten by kvm_emulate_halt and, thus, got lost.
This introduces APIC events for those two signals, keeping them in
kvm_apic until kvm_apic_accept_e
Il 13/03/2013 11:30, Jan Kiszka ha scritto:
> Only interrupt and NMI exiting are mandatory for KVM to work, thus can
> be exposed to the guest unconditionally, virtual NMI exiting is
> optional. So we must not advertise it unless the host supports it.
>
> Introduce the symbolic constant PIN_BASED_
On Wed, Mar 13, 2013 at 12:16:13PM +0100, Jan Kiszka wrote:
> >> @@ -1199,11 +1199,8 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu)
> >>
> >> init_vmcb(svm);
> >>
> >> - if (!kvm_vcpu_is_bsp(vcpu)) {
> >> + if (!kvm_vcpu_is_bsp(vcpu))
> >> kvm_rip_write(vcpu, 0);
>
On 2013-03-13 13:16, Gleb Natapov wrote:
> On Wed, Mar 13, 2013 at 12:16:13PM +0100, Jan Kiszka wrote:
@@ -1199,11 +1199,8 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu)
init_vmcb(svm);
- if (!kvm_vcpu_is_bsp(vcpu)) {
+ if (!kvm_vcpu_is_bsp(vcpu))
>
On Wed, Mar 13, 2013 at 01:17:50PM +0100, Jan Kiszka wrote:
> - svm->vmcb->save.cs.base = svm->vcpu.arch.sipi_vector << 12;
> - svm->vmcb->save.cs.selector = svm->vcpu.arch.sipi_vector
> << 8;
> - }
>
> kvm_cpuid(vcpu, &eax, &dummy, &
Il 13/03/2013 12:42, Jan Kiszka ha scritto:
> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
> was overwritten by kvm_emulate_halt and, thus, got lost.
>
> This introduces APIC events for those two sig
On Wed, Mar 13, 2013 at 12:36:58PM +0100, Jan Kiszka wrote:
> On 2013-03-13 12:16, Jan Kiszka wrote:
> >>> @@ -5871,8 +5867,8 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
> >>> srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx);
> >>> kvm_vcpu_block(vcpu);
>
On Wed, Mar 13, 2013 at 03:42:18PM +0800, Xiao Guangrong wrote:
> On 03/13/2013 03:28 PM, Takuya Yoshikawa wrote:
> > On Wed, 13 Mar 2013 13:06:23 +0800
> > Xiao Guangrong wrote:
> >
> >> On 03/12/2013 04:44 PM, Takuya Yoshikawa wrote:
> >>> This will be used not to zap unrelated mmu pages when c
On 2013-03-13 13:29, Gleb Natapov wrote:
> On Wed, Mar 13, 2013 at 12:36:58PM +0100, Jan Kiszka wrote:
>> On 2013-03-13 12:16, Jan Kiszka wrote:
> @@ -5871,8 +5867,8 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
> srcu_read_unlock(&kvm->srcu, vcpu->srcu_idx);
>
On 2013-03-13 13:27, Paolo Bonzini wrote:
> With the following hack to inject an INIT and corresponding QEMU changes:
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 2609e7b99..efdab35 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -6182,8 +6182,16 @@ int kvm_ar
On 03/13/2013 08:33 PM, Gleb Natapov wrote:
> On Wed, Mar 13, 2013 at 03:42:18PM +0800, Xiao Guangrong wrote:
>> On 03/13/2013 03:28 PM, Takuya Yoshikawa wrote:
>>> On Wed, 13 Mar 2013 13:06:23 +0800
>>> Xiao Guangrong wrote:
>>>
On 03/12/2013 04:44 PM, Takuya Yoshikawa wrote:
> This will
Il 13/03/2013 11:31, Jan Kiszka ha scritto:
> Provided the host has this feature, it's straightforward to offer it to
> the guest as well. We just need to load to timer value on L2 entry if
> the feature was enabled by L1 and watch out for the corresponding exit
> reason.
>
> Signed-off-by: Jan Ki
On Wed, Mar 13, 2013 at 01:40:33PM +0100, Jan Kiszka wrote:
> On 2013-03-13 13:29, Gleb Natapov wrote:
> > On Wed, Mar 13, 2013 at 12:36:58PM +0100, Jan Kiszka wrote:
> >> On 2013-03-13 12:16, Jan Kiszka wrote:
> > @@ -5871,8 +5867,8 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
> >
On 2013-03-13 13:48, Gleb Natapov wrote:
> On Wed, Mar 13, 2013 at 01:40:33PM +0100, Jan Kiszka wrote:
>> On 2013-03-13 13:29, Gleb Natapov wrote:
>>> On Wed, Mar 13, 2013 at 12:36:58PM +0100, Jan Kiszka wrote:
On 2013-03-13 12:16, Jan Kiszka wrote:
>>> @@ -5871,8 +5867,8 @@ static int __v
On Wed, Mar 13, 2013 at 01:58:07PM +0100, Jan Kiszka wrote:
> On 2013-03-13 13:48, Gleb Natapov wrote:
> > On Wed, Mar 13, 2013 at 01:40:33PM +0100, Jan Kiszka wrote:
> >> On 2013-03-13 13:29, Gleb Natapov wrote:
> >>> On Wed, Mar 13, 2013 at 12:36:58PM +0100, Jan Kiszka wrote:
> On 2013-03-13
On Wed, 13 Mar 2013 20:42:41 +0800
Xiao Guangrong wrote:
> How about save all mmio spte into a mmio-rmap?
> >>>
> >>> The problem is that other mmu code would need to care about the pointers
> >>> stored in the new rmap list: when mmu_shrink zaps shadow pages for
> >>> example.
> >>
> >> It
On 03/13/2013 09:40 PM, Takuya Yoshikawa wrote:
> On Wed, 13 Mar 2013 20:42:41 +0800
> Xiao Guangrong wrote:
>
>> How about save all mmio spte into a mmio-rmap?
>
> The problem is that other mmu code would need to care about the pointers
> stored in the new rmap list: when mmu_shr
On Wed, Mar 13, 2013 at 12:42:34PM +0100, Jan Kiszka wrote:
> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
> was overwritten by kvm_emulate_halt and, thus, got lost.
>
> This introduces APIC events f
On Wed, Mar 13, 2013 at 11:30:50AM +0100, Jan Kiszka wrote:
> Only interrupt and NMI exiting are mandatory for KVM to work, thus can
> be exposed to the guest unconditionally, virtual NMI exiting is
> optional. So we must not advertise it unless the host supports it.
>
> Introduce the symbolic con
On Wed, Mar 13, 2013 at 11:31:24AM +0100, Jan Kiszka wrote:
> Provided the host has this feature, it's straightforward to offer it to
> the guest as well. We just need to load to timer value on L2 entry if
> the feature was enabled by L1 and watch out for the corresponding exit
> reason.
>
> Signe
On 2013-03-13 15:44, Gleb Natapov wrote:
> On Wed, Mar 13, 2013 at 11:31:24AM +0100, Jan Kiszka wrote:
>> Provided the host has this feature, it's straightforward to offer it to
>> the guest as well. We just need to load to timer value on L2 entry if
>> the feature was enabled by L1 and watch out f
On 2013-03-13 15:50, Jan Kiszka wrote:
> On 2013-03-13 15:44, Gleb Natapov wrote:
>> On Wed, Mar 13, 2013 at 11:31:24AM +0100, Jan Kiszka wrote:
>>> Provided the host has this feature, it's straightforward to offer it to
>>> the guest as well. We just need to load to timer value on L2 entry if
>>>
We will need EFER.LMA saving to provide unrestricted guest mode. All
what is missing for this is picking up EFER.LMA from VM_ENTRY_CONTROLS
on L2->L1 switches. If the host does not support EFER.LMA saving,
no change is performed, otherwise we properly emulate for L1 what the
hardware does for L0. A
Il 13/03/2013 16:06, Jan Kiszka ha scritto:
> We will need EFER.LMA saving to provide unrestricted guest mode. All
> what is missing for this is picking up EFER.LMA from VM_ENTRY_CONTROLS
> on L2->L1 switches. If the host does not support EFER.LMA saving,
> no change is performed, otherwise we prop
As everyone is so busy taking nVMX patches today, I'm pushing some more:
Patch 1 I already posted earlier, it is still valid. Patch 2 & 3 were
developed out of a previous version which turned out to be incomplete.
Things became more complex since then, but they seem to work correctly
now.
These p
The comment was wrong: enable_irq_window might be called after
prepare_vmcs02 when we left L2 to prepare IRQ injecting for L1. Same for
NMIs.
Signed-off-by: Jan Kiszka
---
arch/x86/kvm/vmx.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/ar
If we are in guest mode, L0 can only inject events into L2 if L1 has
nothing pending. Otherwise, L0 would overwrite L1's events and they
would get lost. This check is conceptually independent of
nested_exit_on_intr.
If L1 traps external interrupts, then we also need to look at L1's
idt_vectoring_i
The changes finally allow to inject interrupts directly from L0 to L2.
The basic idea is to always transfer the pending event injection on
vmexit into the architectural state of the VCPU and then drop it from
there if it turns out that we left L2 to enter L1.
VMX and SVM are now identical in how
Hi Marc,
I wonder if two of these registers could be handled in a generic fashion.
On 03/04/2013 10:47 PM, Marc Zyngier wrote:
> Add the support code for Cortex-A57 specific system registers.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/kvm/sys_regs_a57.c | 96
>
On Feb 8, 2013, at 1:22 PM, Stuart Yoder wrote:
> From: Stuart Yoder
>
> Signed-off-by: Stuart Yoder
> ---
>
> -removed KVM prefix to patch subject, patch is not KVM specific
>
> arch/powerpc/kernel/epapr_hcalls.S |2 ++
> arch/powerpc/kernel/idle_book3e.S | 32
Hi Marc,
I like how you were able to use a common fpsimd_(save|restore) macro, and
wonder if you can't do the same sort of thing for the general purpose
registers and system registers. In the end, both guest and host are EL1
software, and while they may differ in terms of things like VTTBR setting
Hi Marc,
On 03/13/2013 03:48 AM, Marc Zyngier wrote:
> On 12/03/13 22:07, Christopher Covington wrote:
>
> Hi Christopher,
>
>> On 03/12/2013 02:05 PM, Marc Zyngier wrote:
>>> On 12/03/13 17:31, Christopher Covington wrote:
Hi Marc,
On 03/04/2013 10:47 PM, Marc Zyngier wrote:
On 03/08/2013 05:04:30 AM, Alexander Graf wrote:
Am 08.03.2013 um 11:37 schrieb Paul Mackerras :
> On Thu, Mar 07, 2013 at 03:00:52PM +0100, Alexander Graf wrote:
>>
>> Could you please (in a quick and drafty way) try and see if
setting the IRQ arch (using enable_cap) after the vcpu got crea
On 14.03.2013, at 01:14, Scott Wood wrote:
> On 03/08/2013 05:04:30 AM, Alexander Graf wrote:
>> Am 08.03.2013 um 11:37 schrieb Paul Mackerras :
>> > On Thu, Mar 07, 2013 at 03:00:52PM +0100, Alexander Graf wrote:
>> >>
>> >> Could you please (in a quick and drafty way) try and see if setting the
The exynos 5250 SoC supports A15 style architected timers. Indicate
this through the device tree.
This is required by KVM.
Signed-off-by: Alexander Graf
---
arch/arm/boot/dts/exynos5250.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch
The GIC in the exynos5250 SoC is A15 compliant. Show this through
the device tree, so that we can use the GIC for KVM.
Also add the respective A15 memory regions and interrupt links.
Signed-off-by: Alexander Graf
---
arch/arm/boot/dts/exynos5250.dtsi |8 ++--
1 file changed, 6 insertion
While trying to run 3.9 on Arndale with KVM, I ran across a few minor
issues. These patches resolve them, but I'm not 100% sure they are
correct.
I'd be very happy if someone who's deeply into the respective code
paths could take a look here and either ack the patches or suggest
alternative patche
When running on an exynos 5250 SoC, we don't initialize the architected
timers. The chip however supports architected timers.
When we don't initialize them, KVM will try to access them and run into
NULL pointer dereferences attempting to do so.
This patch is really more of a hack than a real fix,
On Wed, Mar 13, 2013 at 07:14:48PM -0500, Scott Wood wrote:
> On 03/08/2013 05:04:30 AM, Alexander Graf wrote:
> >
> >
> >Am 08.03.2013 um 11:37 schrieb Paul Mackerras :
> >
> >> On Thu, Mar 07, 2013 at 03:00:52PM +0100, Alexander Graf wrote:
> >>>
> >>> Could you please (in a quick and drafty way)
Setting this capability on a vcpu connects that vcpu to an interrupt
controller device. The args[0] field of the argument kvm_enable_cap
struct specifies the overall architecture of the interrupt
controller. The args[1] field specifies the CPU number for the vcpu
from the interrupt controller's p
On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> walk and zap all shadow pages one by one, also it need to zap all guest
> page's rmap and all shadow page's parent spte list. Particularly, things
> become wors
On Wed, Mar 13, 2013 at 10:07:06PM -0300, Marcelo Tosatti wrote:
> On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
> > The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
> > walk and zap all shadow pages one by one, also it need to zap all guest
> > page's rmap a
On Wed, Mar 13, 2013 at 10:05:20PM +0800, Xiao Guangrong wrote:
> On 03/13/2013 09:40 PM, Takuya Yoshikawa wrote:
> > On Wed, 13 Mar 2013 20:42:41 +0800
> > Xiao Guangrong wrote:
> >
> >> How about save all mmio spte into a mmio-rmap?
> >
> > The problem is that other mmu code would n
On Wed, Mar 13, 2013 at 12:42:34PM +0100, Jan Kiszka wrote:
> A VCPU sending INIT or SIPI to some other VCPU races for setting the
> remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
> was overwritten by kvm_emulate_halt and, thus, got lost.
>
> This introduces APIC events f
On Wed, Mar 13, 2013 at 09:56:41AM +0100, Paolo Bonzini wrote:
> Il 13/03/2013 08:34, Asias He ha scritto:
> > Currently, vs->vs_endpoint is used indicate if the endpoint is setup or
> > not. It is set or cleared in vhost_scsi_set_endpoint() or
> > vhost_scsi_clear_endpoint() under the vs->dev.mute
> vmx_vcpu_reset overwrites vcpu->srcu_idx if ->vcpu_reset is called from
> within srcu section.
>
> Also, this is not part of the hotpath and therefore it could be farther
> from vcpu_enter_guest. What about processing a new request bit here?
> (KVM_REQ_EVENT <-> apic->pending_events relationship
On Wed, Mar 13, 2013 at 09:02:38AM +0100, Paolo Bonzini wrote:
> Il 13/03/2013 04:13, Asias He ha scritto:
> >> > This takes dev mutex on data path which will introduce
> >> > contention esp for multiqueue.
> > Yes, for now it is okay, but for concurrent execution of multiqueue it is
> > really bad
On Wed, Mar 13, 2013 at 09:00:43AM +0100, Paolo Bonzini wrote:
> Il 13/03/2013 04:02, Asias He ha scritto:
> > On Tue, Mar 12, 2013 at 09:26:18AM +0100, Paolo Bonzini wrote:
> >> Il 12/03/2013 03:42, Asias He ha scritto:
> >>> This helper is useful to check if vs->vs_endpoint is setup by
> >>> vhos
On Tue, Mar 12, 2013 at 12:14:56PM +0100, Paolo Bonzini wrote:
> Il 12/03/2013 12:12, Michael S. Tsirkin ha scritto:
> > On Tue, Mar 12, 2013 at 09:26:42AM +0100, Paolo Bonzini wrote:
> >> Il 12/03/2013 03:42, Asias He ha scritto:
> >>> Asias He (4):
> >>> tcm_vhost: Add missed lock in vhost_scsi
On Wed, 13 Mar 2013 22:58:21 -0300
Marcelo Tosatti wrote:
> > > In zap_spte, don't we need to search the pointer to be removed from the
> > > global mmio-rmap list? How long can that list be?
> >
> > It is not bad. On softmmu, the rmap list has already been long more than
> > 300.
> > On hardm
On Thu, Mar 14, 2013 at 11:26:41AM +0900, Takuya Yoshikawa wrote:
> On Wed, 13 Mar 2013 22:58:21 -0300
> Marcelo Tosatti wrote:
>
> > > > In zap_spte, don't we need to search the pointer to be removed from the
> > > > global mmio-rmap list? How long can that list be?
> > >
> > > It is not bad.
https://bugzilla.kernel.org/show_bug.cgi?id=55201
Summary: host panic when "creating guest, doing scp and killing
QEMU process" continuously
Product: Virtualization
Version: unspecified
Kernel Version: 3.7.0
Platform: All
O
https://bugzilla.kernel.org/show_bug.cgi?id=55201
--- Comment #1 from Jay Ren 2013-03-14 02:57:29 ---
also, I got some info in the console when this bug happens.
-
Message from syslogd@vt-snb9 at Mar 4 15:37:26 ...
kernel:BUG: soft lockup - CPU#15 stuck for 23s! [python:57408]
https://bugzilla.kernel.org/show_bug.cgi?id=55201
--- Comment #2 from Jay Ren 2013-03-14 02:58:06 ---
Created an attachment (id=95371)
--> (https://bugzilla.kernel.org/attachment.cgi?id=95371)
host serial port log when bug happens
--
Configure bugmail: https://bugzilla.kernel.org/userpref
On Wed, Mar 13, 2013 at 5:59 PM, Alexander Graf wrote:
> When running on an exynos 5250 SoC, we don't initialize the architected
> timers. The chip however supports architected timers.
>
> When we don't initialize them, KVM will try to access them and run into
> NULL pointer dereferences attemptin
On Tue, Mar 12, 2013 at 02:29:40PM +0800, Asias He wrote:
> This is on top of Paolo and Nick's work.
>
> Current status:
> Works now (guest boots fine, no hang any more) with seabios's virtio-scsi
> disabled.
> Rebased to latest qemu.org/master
> Change details are in commit log.
>
> TODO:
> Mak
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, March 07, 2013 6:38 PM
> To: Bhushan Bharat-R65777
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
> Bharat-R65777
> Subject: Re: [PATCH 2/7] Added ONE_REG interface for deb
On 03/14/2013 09:35 AM, Marcelo Tosatti wrote:
> On Wed, Mar 13, 2013 at 10:07:06PM -0300, Marcelo Tosatti wrote:
>> On Wed, Mar 13, 2013 at 12:59:12PM +0800, Xiao Guangrong wrote:
>>> The current kvm_mmu_zap_all is really slow - it is holding mmu-lock to
>>> walk and zap all shadow pages one by on
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, March 07, 2013 6:51 PM
> To: Bhushan Bharat-R65777
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
> Bharat-R65777
> Subject: Re: [PATCH 3/7] KVM: PPC: debug stub interface
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, March 07, 2013 6:56 PM
> To: Bhushan Bharat-R65777
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
> Bharat-R65777
> Subject: Re: [PATCH 4/7] booke: Save and restore debug r
On 03/14/2013 09:58 AM, Marcelo Tosatti wrote:
> On Wed, Mar 13, 2013 at 10:05:20PM +0800, Xiao Guangrong wrote:
>> On 03/13/2013 09:40 PM, Takuya Yoshikawa wrote:
>>> On Wed, 13 Mar 2013 20:42:41 +0800
>>> Xiao Guangrong wrote:
>>>
How about save all mmio spte into a mmio-rmap?
>>>
>
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Thursday, March 07, 2013 7:09 PM
> To: Bhushan Bharat-R65777
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
> Bharat-R65777
> Subject: Re: [PATCH 7/7] KVM: PPC: Add userspace debug s
On 03/14/2013 10:39 AM, Marcelo Tosatti wrote:
> On Thu, Mar 14, 2013 at 11:26:41AM +0900, Takuya Yoshikawa wrote:
>> On Wed, 13 Mar 2013 22:58:21 -0300
>> Marcelo Tosatti wrote:
>>
> In zap_spte, don't we need to search the pointer to be removed from the
> global mmio-rmap list? How long
On 03/14/2013 01:13 PM, Xiao Guangrong wrote:
> On 03/14/2013 09:58 AM, Marcelo Tosatti wrote:
>> On Wed, Mar 13, 2013 at 10:05:20PM +0800, Xiao Guangrong wrote:
>>> On 03/13/2013 09:40 PM, Takuya Yoshikawa wrote:
On Wed, 13 Mar 2013 20:42:41 +0800
Xiao Guangrong wrote:
> Ho
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Alexander Graf
> Sent: Thursday, March 07, 2013 4:17 PM
> To: Wood Scott-B07421
> Cc: Bhushan Bharat-R65777; kvm-...@vger.kernel.org; kvm@vger.kernel.org;
> Bhushan
> Bharat-R
88 matches
Mail list logo
