> -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
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
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
> -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 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 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
> -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
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: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 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
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
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
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
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
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.
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 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, 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 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
> 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: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
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 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 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 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
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 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)
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,
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
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
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
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
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:
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
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 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
>
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
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 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
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
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
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
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
>>>
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 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 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 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 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, 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 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 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: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)
> >
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 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
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 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 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 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);
>
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 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, &
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 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);
>
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_
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
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)
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 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
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 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
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
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-
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
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 =
>
-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 =
>>
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
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 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
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 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
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-
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 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,
>>
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
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
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
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
88 matches
Mail list logo
