On Wed, Mar 13, 2013 at 04:06:41PM +0100, Jan Kiszka wrote:
> 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, o
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 Tue, Mar 12, 2013 at 05:43:33PM +0900, Takuya Yoshikawa wrote:
> This is only for mmio spte zapping, not for all zap_all() cases.
>
> Takuya Yoshikawa (2):
> KVM: MMU: Mark sp mmio cached when creating mmio spte
> KVM: x86: Optimize mmio spte zapping when creating/moving memslot
>
> arch/
Il 14/03/2013 03:07, Asias He ha scritto:
> 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
On 13 March 2013 20:34, Christopher Covington wrote:
> My guess at the goal of the code cited above in this email is that it's trying
> to sanity check that virtualization will work. Rather than taking a default
> deny approach with a hand-maintained white list of virtualization-supporting
> machi
On Thu, Mar 14, 2013 at 09:37:23AM +0100, Paolo Bonzini wrote:
> Il 14/03/2013 03:07, Asias He ha scritto:
> > 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
On Thu, Mar 14, 2013 at 12:25:14PM +0800, Asias He wrote:
> 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 lat
On Thu, Mar 14, 2013 at 05:25:42PM +0800, Asias He wrote:
> On Thu, Mar 14, 2013 at 12:25:14PM +0800, Asias He wrote:
> > 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
>> --- 8 ---> seabios patch:
>> diff --git a/src/virtio-scsi.c b/src/virtio-scsi.c
>> index 879ddfb..4de1255 100644
>> --- a/src/virtio-scsi.c
>> +++ b/src/virtio-scsi.c
>> @@ -147,6 +147,9 @@ init_virtio_scsi(struct pci_device *pci)
>> goto fail;
>> }
>>
>>
On 2013-03-14 01:08, Marcelo Tosatti wrote:
> 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, t
On Thu, Mar 14, 2013 at 11:00:24AM +0100, Paolo Bonzini wrote:
>
> >> --- 8 ---> seabios patch:
> >> diff --git a/src/virtio-scsi.c b/src/virtio-scsi.c
> >> index 879ddfb..4de1255 100644
> >> --- a/src/virtio-scsi.c
> >> +++ b/src/virtio-scsi.c
> >> @@ -147,6 +147,9 @@ init
On 13/03/13 18:30, Christopher Covington wrote:
Hi Christopher,
> I wonder if two of these registers could be handled in a generic fashion.
[...]
> What's A57-specific about this MPIDR behavior?
[...]
> What's A57-specific about this CPACR behavior?
In both cases, nothing I can think of. The
https://bugzilla.kernel.org/show_bug.cgi?id=55201
Gleb changed:
What|Removed |Added
CC||g...@redhat.com
--- Comment #3 from Gleb 201
On Thu, Mar 14, 2013 at 11:15:02AM +0100, Jan Kiszka wrote:
> On 2013-03-14 01:08, Marcelo Tosatti wrote:
> > 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_
On 2013-03-14 11:15, Jan Kiszka wrote:
>>>
>>> - if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) {
>>> - pr_debug("vcpu %d received sipi with vector # %x\n",
>>> -vcpu->vcpu_id, vcpu->arch.sipi_vector);
>>> - kvm_lapic_reset(vcpu);
>>> -
On 14.03.2013, at 06:18, Bhushan Bharat-R65777 wrote:
>
>
>> -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
On 14.03.2013, at 05:50, Bhushan Bharat-R65777 wrote:
>
>
>> -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
On 14.03.2013, at 05:42, Bhushan Bharat-R65777 wrote:
>
>
>> -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
On 14.03.2013, at 05:30, Bhushan Bharat-R65777 wrote:
>
>
>> -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
On 2013-03-14 12:54, Alexander Graf wrote:
>
> On 14.03.2013, at 05:42, Bhushan Bharat-R65777 wrote:
>
>>
>>
>>> -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
On 14.03.2013, at 12:57, Jan Kiszka wrote:
> On 2013-03-14 12:54, Alexander Graf wrote:
>>
>> On 14.03.2013, at 05:42, Bhushan Bharat-R65777 wrote:
>>
>>>
>>>
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, March 07, 2013 6:51 PM
To:
On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
> On 2013-03-14 11:15, Jan Kiszka wrote:
> >>>
> >>> - if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) {
> >>> - pr_debug("vcpu %d received sipi with vector # %x\n",
> >>> - vcpu->vcpu_id, vcpu->
On 2013-03-14 13:09, Alexander Graf wrote:
>
> On 14.03.2013, at 12:57, Jan Kiszka wrote:
>
>> On 2013-03-14 12:54, Alexander Graf wrote:
>>>
>>> On 14.03.2013, at 05:42, Bhushan Bharat-R65777 wrote:
>>>
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
On 2013-03-14 13:12, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
>> On 2013-03-14 11:15, Jan Kiszka wrote:
>
> - if (unlikely(vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED)) {
> - pr_debug("vcpu %d received sipi with vector # %x\n",
>>
On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
> On 2013-03-14 13:12, Gleb Natapov wrote:
> > On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
> >> On 2013-03-14 11:15, Jan Kiszka wrote:
> >
> > - if (unlikely(vcpu->arch.mp_state ==
> > KVM_MP_STATE_SIPI
On 14.03.2013, at 13:13, Jan Kiszka wrote:
> On 2013-03-14 13:09, Alexander Graf wrote:
>>
>> On 14.03.2013, at 12:57, Jan Kiszka wrote:
>>
>>> On 2013-03-14 12:54, Alexander Graf wrote:
On 14.03.2013, at 05:42, Bhushan Bharat-R65777 wrote:
>
>
>> -Original Me
On 2013-03-14 13:19, Alexander Graf wrote:
>
> On 14.03.2013, at 13:13, Jan Kiszka wrote:
>
>> On 2013-03-14 13:09, Alexander Graf wrote:
>>>
>>> On 14.03.2013, at 12:57, Jan Kiszka wrote:
>>>
On 2013-03-14 12:54, Alexander Graf wrote:
>
> On 14.03.2013, at 05:42, Bhushan Bharat-R657
On 2013-03-14 13:18, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
>> On 2013-03-14 13:12, Gleb Natapov wrote:
>>> On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
On 2013-03-14 11:15, Jan Kiszka wrote:
>>>
>>> - if (unlikely(vcpu-
On 14.03.2013, at 13:22, Jan Kiszka wrote:
> On 2013-03-14 13:19, Alexander Graf wrote:
>>
>> On 14.03.2013, at 13:13, Jan Kiszka wrote:
>>
>>> On 2013-03-14 13:09, Alexander Graf wrote:
On 14.03.2013, at 12:57, Jan Kiszka wrote:
> On 2013-03-14 12:54, Alexander Graf wrote:
On Thu, Mar 14, 2013 at 01:25:04PM +0100, Jan Kiszka wrote:
> On 2013-03-14 13:18, Gleb Natapov wrote:
> > On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
> >> On 2013-03-14 13:12, Gleb Natapov wrote:
> >>> On Thu, Mar 14, 2013 at 12:29:48PM +0100, Jan Kiszka wrote:
> On 2013-03-14
Windows-host with disabled TX-checksum offloading may send
packets with tcp->checksum=0x. Most likely it is caused
by by Windows algorithm for computing incremental checksum
- see RFC 1624.
RFC1624 (sec.5) states that 0x and 0x are equal, because
for example
0xCD7A + 0x3285 + 0x =
> Dmitry Skorodumov parallels.com> writes:
>
> Windows-host with disabled TX-checksum offloading may send
> packets with tcp->checksum=0x. Most likely it is caused
> by by Windows algorithm for computing incremental checksum
> - see RFC 1624.
Forgot to mention that packets with checksum 0xff
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
> Behalf Of Alexander Graf
> Sent: Thursday, March 14, 2013 5:20 PM
> To: Bhushan Bharat-R65777
> Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421
> Subject: Re: [PATCH
On Wed, Mar 13, 2013 at 05:53:45PM +0100, Jan Kiszka wrote:
> 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 trap
On Thu, Mar 14, 2013 at 11:15:02AM +0100, Jan Kiszka wrote:
> On 2013-03-14 01:08, Marcelo Tosatti wrote:
> > 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_
> >> -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:
vmx_vcpu_reset may now be called while already holding the srcu lock, so
we may overwrite what was already saved there. Also, we lock and unlock
in the same context, thus there was no need to save to the vcpu anyway.
Signed-off-by: Jan Kiszka
---
Marcelo just suggested this as the simplest fix f
On Thu, Mar 14, 2013 at 11:32:59AM -0300, Marcelo Tosatti wrote:
> > > Also the fact kvm_apic_accept_events() is called from sites is annoying,
> > > why is that necessary again?
> >
> > - to avoid having pending events in the APIC when delivering mp_state
> > to user space
> > - to keep mp_stat
On Thu, Mar 14, 2013 at 03:52:11PM +0100, Jan Kiszka wrote:
> vmx_vcpu_reset may now be called while already holding the srcu lock, so
> we may overwrite what was already saved there. Also, we lock and unlock
> in the same context, thus there was no need to save to the vcpu anyway.
>
> Signed-off-
Hello,
have been trying to build a virtual firewall as a POC but having some
difficulty with the networking aspect. On the physical server I have a single
NIC that is connected to the Internet with the IP XXX.XXX.XXX.10 and is bound
to bridge0. I created the first guest, as the firewall, and
On 2013-03-14 16:00, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 03:52:11PM +0100, Jan Kiszka wrote:
>> vmx_vcpu_reset may now be called while already holding the srcu lock, so
>> we may overwrite what was already saved there. Also, we lock and unlock
>> in the same context, thus there was no nee
Il 14/03/2013 16:03, Jan Kiszka ha scritto:
>> > vcpu->srcu_idx = srcu_read_lock()
>> > idx = srcu_read_lock(&vcpu->kvm->srcu);
>> >srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
>> >vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
>> > srcu_read_unlock(&vcpu->kvm->srcu, idx);
>
Hello everybody,
I get read timeout from smart card read by USB passthrough on Centos 6.4
VM with KVM virtualization.
I am using KVM 1.2.0 and kernel 3.2.28 on Centos 5 host machine.
On VM i have installed:
kernel-2.6.32-358.el6.x86_64
libusb-0.1.12-23.el6.x86_64
libusb1-1.0.9-0.6.rc1.el6.x86_
On Thu, Mar 14, 2013 at 04:08:42PM +0100, Paolo Bonzini wrote:
> Il 14/03/2013 16:03, Jan Kiszka ha scritto:
> >> > vcpu->srcu_idx = srcu_read_lock()
> >> > idx = srcu_read_lock(&vcpu->kvm->srcu);
> >> >srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
> >> >vcpu->srcu_idx = srcu_read_
On 2013-03-14 16:08, Paolo Bonzini wrote:
> Il 14/03/2013 16:03, Jan Kiszka ha scritto:
vcpu->srcu_idx = srcu_read_lock()
idx = srcu_read_lock(&vcpu->kvm->srcu);
srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
On Wed, Mar 13, 2013 at 05:53:45PM +0100, Jan Kiszka wrote:
> 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 trap
On 2013-03-14 16:12, Gleb Natapov wrote:
> On Wed, Mar 13, 2013 at 05:53:45PM +0100, Jan Kiszka wrote:
>> 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 indepen
- Original Message -
> From: "Phil Daws"
> To: kvm@vger.kernel.org
> Sent: Thursday, March 14, 2013 10:53:43 AM
> Subject: Virtual Firewall
>
> Hello,
>
> have been trying to build a virtual firewall as a POC but having some
> difficulty with the networking aspect. On the physical ser
On 2013-03-14 13:28, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 01:25:04PM +0100, Jan Kiszka wrote:
>> On 2013-03-14 13:18, Gleb Natapov wrote:
>>> On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
On 2013-03-14 13:12, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 12:29:48PM +
On 2013-03-14 14:59, Gleb Natapov wrote:
> On Wed, Mar 13, 2013 at 05:53:45PM +0100, Jan Kiszka wrote:
>> 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 indepen
On Thu, Mar 14, 2013 at 04:24:18PM +0100, Jan Kiszka wrote:
> On 2013-03-14 16:12, Gleb Natapov wrote:
> > On Wed, Mar 13, 2013 at 05:53:45PM +0100, Jan Kiszka wrote:
> >> If we are in guest mode, L0 can only inject events into L2 if L1 has
> >> nothing pending. Otherwise, L0 would overwrite L1's e
On 2013-03-14 16:37, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 04:24:18PM +0100, Jan Kiszka wrote:
>> On 2013-03-14 16:12, Gleb Natapov wrote:
>>> On Wed, Mar 13, 2013 at 05:53:45PM +0100, Jan Kiszka wrote:
If we are in guest mode, L0 can only inject events into L2 if L1 has
nothing p
Il 14/03/2013 16:11, Gleb Natapov ha scritto:
> On Thu, Mar 14, 2013 at 04:08:42PM +0100, Paolo Bonzini wrote:
>> Il 14/03/2013 16:03, Jan Kiszka ha scritto:
> vcpu->srcu_idx = srcu_read_lock()
> idx = srcu_read_lock(&vcpu->kvm->srcu);
>srcu_read_unlock(&vcpu->kvm->srcu, vcpu->sr
On Thu, Mar 14, 2013 at 04:32:16PM +0100, Jan Kiszka wrote:
> On 2013-03-14 13:28, Gleb Natapov wrote:
> > On Thu, Mar 14, 2013 at 01:25:04PM +0100, Jan Kiszka wrote:
> >> On 2013-03-14 13:18, Gleb Natapov wrote:
> >>> On Thu, Mar 14, 2013 at 01:16:41PM +0100, Jan Kiszka wrote:
> On 2013-03-14
- Original Message -
From: "Andrew Cathrow"
To: "Phil Daws"
Cc: kvm@vger.kernel.org
Sent: Thursday, 14 March, 2013 3:30:50 PM
Subject: Re: Virtual Firewall
- Original Message -
This is well supported in libvirt [1]
If you don't want to use libvirt then you can at least run
On 03/14/2013 08:57:53 AM, Bhushan Bharat-R65777 wrote:
> >>> diff --git a/arch/powerpc/kvm/e500mc.c
b/arch/powerpc/kvm/e500mc.c
> >>> index 1f89d26..f5fc6f5 100644
> >>> --- a/arch/powerpc/kvm/e500mc.c
> >>> +++ b/arch/powerpc/kvm/e500mc.c
> >>> @@ -182,8 +182,7 @@ int kvmppc_core_vcpu_setup(s
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, March 14, 2013 9:36 PM
> To: Bhushan Bharat-R65777
> Cc: Alexander Graf; kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-
> B07421
> Subject: Re: [PATCH 7/7] KVM: PPC: Add userspace debug stub support
>
> On 03/14/
On 03/13/2013 08:26:20 PM, Paul Mackerras wrote:
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:
> >>>
On 03/13/2013 08:20:44 PM, Paul Mackerras wrote:
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 nu
On 14.03.2013, at 19:20, Scott Wood wrote:
> On 03/13/2013 08:20:44 PM, Paul Mackerras wrote:
>> 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 interru
On 03/14/2013 01:33:30 PM, Alexander Graf wrote:
On 14.03.2013, at 19:20, Scott Wood wrote:
> On 03/13/2013 08:20:44 PM, Paul Mackerras wrote:
>> Setting this capability on a vcpu connects that vcpu to an
interrupt
>> controller device. The args[0] field of the argument
kvm_enable_cap
>>
On 14.03.2013, at 19:35, Scott Wood wrote:
> On 03/14/2013 01:33:30 PM, Alexander Graf wrote:
>> On 14.03.2013, at 19:20, Scott Wood wrote:
>> > On 03/13/2013 08:20:44 PM, Paul Mackerras wrote:
>> >> Setting this capability on a vcpu connects that vcpu to an interrupt
>> >> controller device. Th
Hello.
On 14-03-2013 4:59, 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 attempting to do so
On 03/14/2013 02:03:30 PM, Alexander Graf wrote:
On 14.03.2013, at 19:35, Scott Wood wrote:
> On 03/14/2013 01:33:30 PM, Alexander Graf wrote:
>> On 14.03.2013, at 19:20, Scott Wood wrote:
>> > On 03/13/2013 08:20:44 PM, Paul Mackerras wrote:
>> >> Setting this capability on a vcpu connects tha
On Thu, Mar 14, 2013 at 05:00:04PM +0200, Gleb Natapov wrote:
> On Thu, Mar 14, 2013 at 03:52:11PM +0100, Jan Kiszka wrote:
> > vmx_vcpu_reset may now be called while already holding the srcu lock, so
> > we may overwrite what was already saved there. Also, we lock and unlock
> > in the same contex
On 2013-03-14 20:14, Marcelo Tosatti wrote:
> On Thu, Mar 14, 2013 at 05:00:04PM +0200, Gleb Natapov wrote:
>> On Thu, Mar 14, 2013 at 03:52:11PM +0100, Jan Kiszka wrote:
>>> vmx_vcpu_reset may now be called while already holding the srcu lock, so
>>> we may overwrite what was already saved there.
vmx_vcpu_reset may now be called while already holding the srcu lock, so
we may overwrite what was already saved there. Save and restore it.
Signed-off-by: Jan Kiszka
---
Even if this should be unneeded, it looks more consistent. In any case,
all versions on the table, pick what you prefer.
ar
On Thu, Mar 14, 2013 at 08:20:26PM +0100, Jan Kiszka wrote:
> >> Not sure this is valid.
> >
> > The lock/unlocks must be paired.
>
> Did you find out more than what Paolo reported?
/**
* srcu_read_unlock - unregister a old reader from an SRCU-protected
* structure.
* @sp: srcu_struct in whic
On 14.03.2013, at 20:10, Scott Wood wrote:
> On 03/14/2013 02:03:30 PM, Alexander Graf wrote:
>> On 14.03.2013, at 19:35, Scott Wood wrote:
>> > On 03/14/2013 01:33:30 PM, Alexander Graf wrote:
>> >> On 14.03.2013, at 19:20, Scott Wood wrote:
>> >> > On 03/13/2013 08:20:44 PM, Paul Mackerras wrot
The vfio drivers call kmalloc or kzalloc, but do not
include , which causes build errors on
ARM.
Signed-off-by: Arnd Bergmann
Cc: Alex Williamson
Cc: kvm@vger.kernel.org
---
Please apply for 3.9
drivers/vfio/pci/vfio_pci_config.c | 1 +
drivers/vfio/pci/vfio_pci_intrs.c | 1 +
2 files changed
On Thu, Mar 14, 2013 at 01:15:35PM -0500, Scott Wood wrote:
> On 03/13/2013 08:26:20 PM, Paul Mackerras wrote:
> >I arbitrarily
> >assigned 0x58494353 for KVM_CAP_IRQ_XICS as the args[0] value to
> >indicate XICS.
>
> Why is it called KVM_CAP_ if it's not a capability?
Because it's associated wi
On Thu, Mar 14, 2013 at 01:20:38PM -0500, Scott Wood wrote:
> On 03/13/2013 08:20:44 PM, Paul Mackerras wrote:
> >--- a/arch/powerpc/include/asm/kvm_host.h
> >+++ b/arch/powerpc/include/asm/kvm_host.h
> >@@ -373,6 +373,9 @@ struct kvmppc_booke_debug_reg {
> > struct kvm_vcpu_arch {
> > ulong h
On Thu, Mar 14, 2013 at 08:03:30PM +0100, Alexander Graf wrote:
>
> On 14.03.2013, at 19:35, Scott Wood wrote:
>
> > On 03/14/2013 01:33:30 PM, Alexander Graf wrote:
> >> We also want int pic_fd, no?
> >
> > Not sure we really need that on the vcpu. We'll need it on the vm unless
> > we add it
On 03/14/2013 05:28:03 PM, Paul Mackerras wrote:
On Thu, Mar 14, 2013 at 08:03:30PM +0100, Alexander Graf wrote:
>
> On 14.03.2013, at 19:35, Scott Wood wrote:
>
> > On 03/14/2013 01:33:30 PM, Alexander Graf wrote:
> >> We also want int pic_fd, no?
> >
> > Not sure we really need that on the vcpu
On 03/14/2013 05:19:17 PM, Paul Mackerras wrote:
On Thu, Mar 14, 2013 at 01:20:38PM -0500, Scott Wood wrote:
> On 03/13/2013 08:20:44 PM, Paul Mackerras wrote:
> >--- a/arch/powerpc/include/asm/kvm_host.h
> >+++ b/arch/powerpc/include/asm/kvm_host.h
> >@@ -373,6 +373,9 @@ struct kvmppc_booke_deb
On 14.03.2013, at 23:02, Paul Mackerras wrote:
> On Thu, Mar 14, 2013 at 01:15:35PM -0500, Scott Wood wrote:
>> On 03/13/2013 08:26:20 PM, Paul Mackerras wrote:
>
>>> I arbitrarily
>>> assigned 0x58494353 for KVM_CAP_IRQ_XICS as the args[0] value to
>>> indicate XICS.
>>
>> Why is it called KVM
On 03/14/2013 05:44:39 PM, Alexander Graf wrote:
On 14.03.2013, at 23:02, Paul Mackerras wrote:
> On Thu, Mar 14, 2013 at 01:15:35PM -0500, Scott Wood wrote:
>> On 03/13/2013 08:26:20 PM, Paul Mackerras wrote:
>
>>> I arbitrarily
>>> assigned 0x58494353 for KVM_CAP_IRQ_XICS as the args[0] value
The new context tracking subsystem unconditionally includes kvm_host.h
headers for the guest enter/exit macros. This causes a compile
failure when KVM is not enabled.
Fix by adding an IS_ENABLED(CONFIG_KVM) check to kvm_host so it can
be included/compiled even when KVM is not enabled.
Cc: Freder
On Thu, Mar 14, 2013 at 11:46:43AM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 14, 2013 at 05:25:42PM +0800, Asias He wrote:
> > On Thu, Mar 14, 2013 at 12:25:14PM +0800, Asias He wrote:
> > > On Tue, Mar 12, 2013 at 02:29:40PM +0800, Asias He wrote:
> > > > This is on top of Paolo and Nick's wo
On Thu, Mar 14, 2013 at 11:00:24AM +0100, Paolo Bonzini wrote:
>
> >> --- 8 ---> seabios patch:
> >> diff --git a/src/virtio-scsi.c b/src/virtio-scsi.c
> >> index 879ddfb..4de1255 100644
> >> --- a/src/virtio-scsi.c
> >> +++ b/src/virtio-scsi.c
> >> @@ -147,6 +147,9 @@ init
Hello Nicholas & Michael,
Could any of you pick this series up?
Changes in v3
- Add more comments
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_endpo
tv_tpg->tv_tpg_vhost_count should be protected by tv_tpg->tv_tpg_mutex.
Signed-off-by: Asias He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Paolo Bonzini
---
drivers/vhost/tcm_vhost.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/tcm_vhost.c b/dri
We also need to flush the vhost_works. It is the completion vhost_work
currently.
Signed-off-by: Asias He
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Paolo Bonzini
---
drivers/vhost/tcm_vhost.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/vhost/tcm_vhost.c b/drivers/vhost/tcm_vhos
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
Asias He (2):
virtio-scsi: Set _DRIVER_OK flag before scsi target scanning
virtio-scsi: Pack struct virtio_scsi_{req_cmd,resp_cmd}
src/virtio-scsi.c | 5 +++--
src/virtio-scsi.h | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
--
1.8.1.4
--
To unsubscribe from this list: send the
Before we start scsi target scanning, we need to set the
VIRTIO_CONFIG_S_DRIVER_OK flag so the device can do setup properly.
This fix a bug when booting tcm_vhost with seabios.
Signed-off-by: Asias He
Acked-by: Paolo Bonzini
---
src/virtio-scsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 d
Device needs the exact size of these data structure. Prevent padding.
This fixes guest hang when booting seabios + tcm_vhost.
Signed-off-by: Asias He
---
src/virtio-scsi.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/virtio-scsi.h b/src/virtio-scsi.h
index bbfbf30
ARCH=mips, config=fuloong2e_defconfig:
akpm3:/usr/src/25> make arch/mips/kernel/early_printk.o
...
CC arch/mips/kernel/asm-offsets.s
In file included from arch/mips/kernel/asm-offsets.c:20:
include/linux/kvm_host.h:334: error: `KVM_USER_MEM_SLOTS' undeclared here (not
in a function)
Report
- Rename KVM_MEMORY_SLOTS -> KVM_USER_MEM_SLOTS
- Fix kvm_arch_{prepare,commit}_memory_region()
- Also remove kvm_arch_set_memory_region which was unused.
Signed-off-by: Sanjay Lal
---
arch/mips/include/asm/kvm_host.h | 2 +-
arch/mips/kvm/kvm_mips.c | 12 ++--
2 files changed,
https://bugzilla.kernel.org/show_bug.cgi?id=55201
--- Comment #4 from Marcelo Tosatti 2013-03-15 02:26:12
---
Created an attachment (id=95451)
--> (https://bugzilla.kernel.org/attachment.cgi?id=95451)
kvm-fix-inprogress-clock-update-deadlock.patch
--
Configure bugmail: https://bugzilla.k
https://bugzilla.kernel.org/show_bug.cgi?id=55201
Marcelo Tosatti changed:
What|Removed |Added
CC||mtosa...@redhat.com
--- Comment #5
Ingo Molnar wrote on 2013-03-08:
>
> * Gleb Natapov wrote:
>
>> On Fri, Mar 08, 2013 at 03:05:45PM +0100, Ingo Molnar wrote:
>>>
>>> * Gleb Natapov wrote:
>>>
On Fri, Mar 08, 2013 at 02:26:25PM +0100, Ingo Molnar wrote:
>
> * Yang Zhang wrote:
>
>> diff --git a/arch/x8
https://bugzilla.kernel.org/show_bug.cgi?id=55201
--- Comment #6 from Jay Ren 2013-03-15 02:45:02 ---
(In reply to comment #5)
> Jay Ren, would you please confirm whether the attached patch fixes the
> problem.
Sure, I'll give the feedback when I get the testing result.
--
Configure bugma
93 matches
Mail list logo
