Anthony Liguori anth...@codemonkey.ws wrote on 28/11/2013 12:33:36 AM:
From: Anthony Liguori anth...@codemonkey.ws
To: Abel Gordon/Haifa/IBM@IBMIL, Michael S. Tsirkin m...@redhat.com,
Cc: abel.gor...@gmail.com, as...@redhat.com, digitale...@google.com,
Eran Raichstein/Haifa/IBM@IBMIL,
Hi all
I am using branch kvm-arm-next-arndale in
git.linaro.org/people/cdall/linux-kvm-arm.git. But i found there is no network
after i burn the new kernel to my board. Is this a known issue? I also found
another guy also see the same issue on his arndale board.
Thanks
young
On 11/27/2013 03:58 AM, Marcelo Tosatti wrote:
On Tue, Nov 26, 2013 at 11:10:19AM +0800, Xiao Guangrong wrote:
On 11/25/2013 10:23 PM, Marcelo Tosatti wrote:
On Mon, Nov 25, 2013 at 02:48:37PM +0200, Avi Kivity wrote:
On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
On 11/27/2013 03:31 AM, Marcelo Tosatti wrote:
On Tue, Nov 26, 2013 at 11:21:37AM +0800, Xiao Guangrong wrote:
On 11/26/2013 02:12 AM, Marcelo Tosatti wrote:
On Mon, Nov 25, 2013 at 02:29:03PM +0800, Xiao Guangrong wrote:
Also, there is no guarantee of termination (as long as sptes are
On Wed, Nov 27, 2013 at 09:06:36AM -0800, Paul E. McKenney wrote:
On Wed, Nov 27, 2013 at 10:00:09AM +0200, Gleb Natapov wrote:
On Tue, Nov 26, 2013 at 11:35:06AM -0800, Paul E. McKenney wrote:
On Tue, Nov 26, 2013 at 06:24:13PM +0200, Michael S. Tsirkin wrote:
On Wed, Sep 12, 2012 at
Il 28/11/2013 07:27, Zhanghaoyu (A) ha scritto:
Without synchronize_rcu you could have
VCPU writes to routing table
e = entry from IRQ routing table
kvm_irq_routing_update(kvm, new);
VCPU resumes execution
No, this would be exactly the same code that is running now:
mutex_lock(kvm-irq_lock);
old = kvm-irq_routing;
kvm_irq_routing_update(kvm, new);
mutex_unlock(kvm-irq_lock);
synchronize_rcu();
kfree(old);
On Thu, Nov 28, 2013 at 09:55:42AM +0100, Paolo Bonzini wrote:
Il 28/11/2013 07:27, Zhanghaoyu (A) ha scritto:
Without synchronize_rcu you could have
VCPU writes to routing table
e = entry from IRQ routing table
kvm_irq_routing_update(kvm,
On Thu, Nov 28, 2013 at 09:14:22AM +, Zhanghaoyu (A) wrote:
No, this would be exactly the same code that is running now:
mutex_lock(kvm-irq_lock);
old = kvm-irq_routing;
kvm_irq_routing_update(kvm, new);
Il 28/11/2013 10:19, Gleb Natapov ha scritto:
Not changing current behaviour is certainly safer, but I am still not 100%
convinced we have to ensure this.
Suppose guest does:
1: change msi interrupt by writing to pci register
2: read the pci register to flush the write
3: zero idt
I
On Thu, Nov 28, 2013 at 10:29:36AM +0100, Paolo Bonzini wrote:
Il 28/11/2013 10:19, Gleb Natapov ha scritto:
Not changing current behaviour is certainly safer, but I am still not 100%
convinced we have to ensure this.
Suppose guest does:
1: change msi interrupt by writing to pci
On 11/28/2013 11:19 AM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 09:55:42AM +0100, Paolo Bonzini wrote:
Il 28/11/2013 07:27, Zhanghaoyu (A) ha scritto:
Without synchronize_rcu you could have
VCPU writes to routing table
e = entry from IRQ routing
Il 28/11/2013 10:49, Avi Kivity ha scritto:
Linux is safe, it does interrupt migration from within the interrupt
handler. If you do that before the device-specific EOI, you won't get
another interrupt until programming the MSI is complete.
Is virtio safe? IIRC it can post multiple
On Thu, Nov 28, 2013 at 11:49:00AM +0200, Avi Kivity wrote:
On 11/28/2013 11:19 AM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 09:55:42AM +0100, Paolo Bonzini wrote:
Il 28/11/2013 07:27, Zhanghaoyu (A) ha scritto:
Without synchronize_rcu you could have
VCPU writes to routing table
On 11/28/2013 12:11 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 11:49:00AM +0200, Avi Kivity wrote:
On 11/28/2013 11:19 AM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 09:55:42AM +0100, Paolo Bonzini wrote:
Il 28/11/2013 07:27, Zhanghaoyu (A) ha scritto:
Without synchronize_rcu you could
On 11/28/2013 11:53 AM, Paolo Bonzini wrote:
Il 28/11/2013 10:49, Avi Kivity ha scritto:
Linux is safe, it does interrupt migration from within the interrupt
handler. If you do that before the device-specific EOI, you won't get
another interrupt until programming the MSI is complete.
Is
Il 28/11/2013 11:16, Avi Kivity ha scritto:
The QRCU I linked would work great latency-wise (it has roughly the same
latency of an rwsem but readers are lock-free). However, the locked
operations in the read path would hurt because of cache misses, so it's
not good either.
I guess srcu
Redington k ltd
New pricelist
X351 (Surf smart 3G) @ Ksh 7,550
X402 (Diamond) @ Ksh 16,850
X450(Race bolt) @ Ksh 15,100
X451(Race bolt Q) @ Ksh 19,150
X500(Race eagle)@ Ksh 16,850
X530(Race maxQ) @ Ksh 19,380
X570(Alpha) @ Ksh 28,080
X800(Joypad) @ Ksh 18,560
Regards,
0738999025
Mathu
--
To
On 11/28/2013 12:40 PM, Paolo Bonzini wrote:
Il 28/11/2013 11:16, Avi Kivity ha scritto:
The QRCU I linked would work great latency-wise (it has roughly the same
latency of an rwsem but readers are lock-free). However, the locked
operations in the read path would hurt because of cache misses,
On Thu, Nov 28, 2013 at 09:31:50AM +0200, Abel Gordon wrote:
Isolation is important but the question is what isolation means ?
Mostly two things:
- Count resource usage against the correct cgroups,
and limit it as appropriate
- If one user does something silly and is blocked,
another user
On Thu, Nov 28, 2013 at 12:12:55PM +0200, Avi Kivity wrote:
On 11/28/2013 12:11 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 11:49:00AM +0200, Avi Kivity wrote:
On 11/28/2013 11:19 AM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 09:55:42AM +0100, Paolo Bonzini wrote:
Il 28/11/2013 07:27,
On Thu, Nov 28, 2013 at 11:40:06AM +0100, Paolo Bonzini wrote:
Il 28/11/2013 11:16, Avi Kivity ha scritto:
The QRCU I linked would work great latency-wise (it has roughly the same
latency of an rwsem but readers are lock-free). However, the locked
operations in the read path would hurt
Il 28/11/2013 12:09, Gleb Natapov ha scritto:
- if there are no callbacks, but there are readers, synchronize_srcu
busy-loops for some time checking if the readers complete. After a
while (20 us for synchronize_srcu, 120 us for
synchronize_srcu_expedited) it gives up and starts using a
On 11/28/2013 01:10 PM, Paolo Bonzini wrote:
Il 28/11/2013 12:09, Gleb Natapov ha scritto:
- if there are no callbacks, but there are readers, synchronize_srcu
busy-loops for some time checking if the readers complete. After a
while (20 us for synchronize_srcu, 120 us for
On 11/28/2013 01:02 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 12:12:55PM +0200, Avi Kivity wrote:
On 11/28/2013 12:11 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 11:49:00AM +0200, Avi Kivity wrote:
On 11/28/2013 11:19 AM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 09:55:42AM
On Thu, Nov 28, 2013 at 01:18:54PM +0200, Avi Kivity wrote:
On 11/28/2013 01:02 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 12:12:55PM +0200, Avi Kivity wrote:
On 11/28/2013 12:11 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 11:49:00AM +0200, Avi Kivity wrote:
On 11/28/2013 11:19 AM,
On Thu, Nov 28, 2013 at 12:10:40PM +0100, Paolo Bonzini wrote:
Il 28/11/2013 12:09, Gleb Natapov ha scritto:
- if there are no callbacks, but there are readers, synchronize_srcu
busy-loops for some time checking if the readers complete. After a
while (20 us for synchronize_srcu, 120 us
On Thu, Nov 28, 2013 at 01:22:45PM +0200, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 01:18:54PM +0200, Avi Kivity wrote:
On 11/28/2013 01:02 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 12:12:55PM +0200, Avi Kivity wrote:
On 11/28/2013 12:11 PM, Gleb Natapov wrote:
On Thu, Nov 28,
On 11/28/2013 01:22 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 01:18:54PM +0200, Avi Kivity wrote:
On 11/28/2013 01:02 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 12:12:55PM +0200, Avi Kivity wrote:
On 11/28/2013 12:11 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 11:49:00AM
Il 28/11/2013 12:23, Gleb Natapov ha scritto:
Unless what ? :) Unless reader is scheduled out?
Yes. Or unless my brain is scheduled out in the middle of a sentence.
So we will have to disable preemption in a reader to prevent big latencies for
a writer, no?
I don't think that's
On 11/28/2013 01:31 PM, Paolo Bonzini wrote:
Il 28/11/2013 12:23, Gleb Natapov ha scritto:
Unless what ? :) Unless reader is scheduled out?
Yes. Or unless my brain is scheduled out in the middle of a sentence.
So we will have to disable preemption in a reader to prevent big latencies for
a
On Thu, Nov 28, 2013 at 01:33:48PM +0200, Michael S. Tsirkin wrote:
On Thu, Nov 28, 2013 at 01:22:45PM +0200, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 01:18:54PM +0200, Avi Kivity wrote:
On 11/28/2013 01:02 PM, Gleb Natapov wrote:
On Thu, Nov 28, 2013 at 12:12:55PM +0200, Avi Kivity
From: Thomas Huth th...@linux.vnet.ibm.com
The SIE_INTERCEPT_UCONTROL can be removed by moving the related code
from kvm_arch_vcpu_ioctl_run() to vcpu_post_run().
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Acked-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Cornelia Huck
address (2013-11-27 17:56:36 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git
tags/kvm-s390-20131128
for you to fetch changes up to 36daca9bb36f0395755817d1b0c45ab6fbf0441b:
KVM: s390: Removed kvm_s390_inject_sigp_stop() (2013
From: Thomas Huth th...@linux.vnet.ibm.com
The TPI handler currently uses vcpu-run-s.regs.crs[6] to get the current
value of CR6. I think this is wrong, because vcpu-run-s.regs.crs is
only updated when kvm_arch_vcpu_ioctl_run() drops back to userspace.
So let's change the TPI handler to use
From: Thomas Huth th...@linux.vnet.ibm.com
The EQBS and SQBS instructions do not set CC3 for invalid channels, but
should throw an operation exception instead when not available. Thus they
should not be handled by the handle_io_inst() wrapper but drop to userspace
instead (which will then inject
From: Thomas Huth th...@linux.vnet.ibm.com
The STORE STATUS AT ADDRESS order of SIGP was still missing.
Now it is supported, using the common kvm_s390_store_status()
function.
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Reviewed-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by:
From: Heiko Carstens heiko.carst...@de.ibm.com
The diagnose code to be used is the contents of the base register (if not
zero), plus the displacement. The current code ignores the base register
contents. So let's fix that...
Reviewed-by: Cornelia Huck cornelia.h...@de.ibm.com
Cc:
From: Thomas Huth th...@linux.vnet.ibm.com
Only the most 7 significant bytes of the clock comparator must be
saved to the status area, and the byte at offset 304 has to be zero.
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Reviewed-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by:
From: Thomas Huth th...@linux.vnet.ibm.com
The SIGP order STOP_AND_STORE_STATUS is defined to stop a CPU and store
its status. However, we only stored the status if the CPU was still
running, so make sure that the status is now also stored if the CPU was
already stopped. This fixes the problem
From: Thomas Huth th...@linux.vnet.ibm.com
VIRTIODESCSPACE is completely unused nowadays and thus can be removed
without any problems.
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Acked-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
From: Thomas Huth th...@linux.vnet.ibm.com
The function kvm_s390_inject_sigp_stop() as been unused since the
removal of the old mmu reload code and thus can be removed safely.
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Reviewed-by: Cornelia Huck cornelia.h...@de.ibm.com
Signed-off-by:
0a00a775d2a49d16efba721c786859844184599c:
KVM: Change maintainer email address (2013-11-27 17:56:36 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git
tags/kvm-s390-20131128
for you to fetch changes up
I have networking with this kernel, but you need to enable
CONFIG_USB_HSIC_USB3503=y
hope this helps.
-Christoffer
On 28 November 2013 00:21, young jams young.kvm@outlook.com wrote:
Hi all
I am using branch kvm-arm-next-arndale in
git.linaro.org/people/cdall/linux-kvm-arm.git. But i
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch make sure we inherit the LE bit correctly in different case
so that we can run Little Endian distro in PR mode
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
Changes from V1:
* Use LPCR bit to find whether to
On 11/28/2013 04:53 PM, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch make sure we inherit the LE bit correctly in different case
so that we can run Little Endian distro in PR mode
IMHO H_SET_MODE should be handled in user space for most cases. We
Alex,
I suppose Scott already elaborate anything you want to know.
Tiejun
On 11/19/2013 05:09 AM, Alexander Graf wrote:
On 18.11.2013, at 03:34, �tiejun.chen� tiejun.c...@windriver.com wrote:
On 10/23/2013 09:26 AM, Tiejun Chen wrote:
We enter with interrupts disabled in hardware, but we
When we run book3s pr kvm with CONFIG_PREEMPT=y badness occurs.
The reason is that we don't expect interrups to occur in the exit
path until we hit the point where we enable interrupts (after the
svcpu sync).
However thanks to our manual interrupt replay logic we do get
preempted because the
The kvmppc_copy_{to,from}_svcpu functions are publically visible,
so we should also export them in a header for others C files to
consume.
So far we didn't need this because we only called it from asm code.
The next patch will introduce a C caller.
Signed-off-by: Alexander Graf ag...@suse.de
---
As soon as we get back to our highmem handler in virtual address
space we may get preempted. Today the reason we can get preempted is
that we replay interrupts and all the lazy logic thinks we have
interrupts enabled.
However, it's not hard to make the code interruptible and that way
we can
Now that the svcpu sync is interrupt aware we can enable interrupts
earlier in the exit code path again, moving 32bit and 64bit closer
together.
While at it, document the fact that we're always executing the exit
path with interrupts enabled so that the next person doesn't trap
over this.
We call a C helper to save all svcpu fields into our vcpu. The C
ABI states that r12 is considered volatile. However, we keep our
exit handler id in r12 currently.
So we need to save it away into a non-volatile register instead
that definitely does get preserved across the C call.
This bug
Hi Alex,
I am running KVM guest with host kernel having CONFIG_PREEMPT enabled. With
allocated pages things seems to work fine but I uses hugepages for guest I see
below prints when quit from qemu.
(qemu) QEMU waiting for connection on: telnet:0.0.0.0:,server
qemu-system-ppc64:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch make sure we inherit the LE bit correctly in different case
so that we can run Little Endian distro in PR mode
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
Changes from V1:
* Use LPCR bit to find whether to
On 11/28/2013 04:53 PM, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch make sure we inherit the LE bit correctly in different case
so that we can run Little Endian distro in PR mode
IMHO H_SET_MODE should be handled in user space for most cases. We
Now that the svcpu sync is interrupt aware we can enable interrupts
earlier in the exit code path again, moving 32bit and 64bit closer
together.
While at it, document the fact that we're always executing the exit
path with interrupts enabled so that the next person doesn't trap
over this.
We call a C helper to save all svcpu fields into our vcpu. The C
ABI states that r12 is considered volatile. However, we keep our
exit handler id in r12 currently.
So we need to save it away into a non-volatile register instead
that definitely does get preserved across the C call.
This bug
When we run book3s pr kvm with CONFIG_PREEMPT=y badness occurs.
The reason is that we don't expect interrups to occur in the exit
path until we hit the point where we enable interrupts (after the
svcpu sync).
However thanks to our manual interrupt replay logic we do get
preempted because the
Hi Alex,
I am running KVM guest with host kernel having CONFIG_PREEMPT enabled. With
allocated pages things seems to work fine but I uses hugepages for guest I see
below prints when quit from qemu.
(qemu) QEMU waiting for connection on: telnet:0.0.0.0:,server
qemu-system-ppc64:
59 matches
Mail list logo
