We shouldn't try Load-Exclusive instructions unless we've enabled memory
management, as these instructions depend on the data cache unit's
coherency monitor. This patch adds a new setup boolean, initialized to false,
that is used to guard Load-Exclusive instructions. Eventually we'll add more
setup
CC linux-kernel
Original thread:
http://comments.gmane.org/gmane.linux.kernel.virtualization/22775
On Mon, Sep 15, 2014 at 06:48:46PM +0200, Radim Krčmář wrote:
> 2014-09-14 10:25+0800, Amos Kong:
> > On Sun, Sep 14, 2014 at 09:12:08AM +0800, Amos Kong wrote:
> >
> > ...
> > > > > > diff --git
On Mon, Sep 15, 2014 at 06:13:20PM +0200, Michael Büsch wrote:
> On Tue, 16 Sep 2014 00:02:27 +0800
> Amos Kong wrote:
>
> > It doesn't save too much cpu time as expected, just a cleanup.
> >
> > Signed-off-by: Amos Kong
> > ---
> > drivers/char/hw_random/core.c | 6 +++---
> > 1 file changed,
On Mon, Sep 15, 2014 at 06:13:31PM +0200, Michael Büsch wrote:
> On Tue, 16 Sep 2014 00:02:29 +0800
> Amos Kong wrote:
>
> > This patch increases the schedule timeout to 10 jiffies, it's more
> > appropriate, then other takes can easy to hold the mutex lock.
> >
> > Signed-off-by: Amos Kong
> >
On 09/15/2014 03:33 PM, Radim Krčmář wrote:
> 2014-09-12 17:06-0400, Liang Chen:
>> Using kvm_mmu_flush_tlb as the other places to make sure vcpu
>> stat is incremented
>>
>> Signed-off-by: Liang Chen
>> ---
> Good catch.
>
>> arch/x86/kvm/vmx.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 dele
When KVM handles a tdp fault it uses FOLL_NOWAIT. If the guest memory has been
swapped out or is behind a filemap, this will trigger async readahead and
return immediately. The rationale is that KVM will kick back the guest with an
"async page fault" and allow for some other guest process to take o
2014-09-12 17:06-0400, Liang Chen:
> Using kvm_mmu_flush_tlb as the other places to make sure vcpu
> stat is incremented
>
> Signed-off-by: Liang Chen
> ---
Good catch.
> arch/x86/kvm/vmx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86
On Tue, Sep 09, 2014 at 11:53:49PM -0700, Matt Mullins wrote:
> On Mon, Sep 08, 2014 at 06:18:46PM +0200, Paolo Bonzini wrote:
> > What version of QEMU? Can you try the 12.04 qemu (which IIRC is 1.0) on
> > top of the newer kernel?
>
> I did reproduce this on qemu 1.0.1.
>
> What would you like
2014-09-14 10:25+0800, Amos Kong:
> On Sun, Sep 14, 2014 at 09:12:08AM +0800, Amos Kong wrote:
>
> ...
> > > > > diff --git a/drivers/char/hw_random/core.c
> > > > > b/drivers/char/hw_random/core.c
> > > > > index c591d7e..b5d1b6f 100644
> > > > > --- a/drivers/char/hw_random/core.c
> > > > > +++
On Tue, 16 Sep 2014 00:02:29 +0800
Amos Kong wrote:
> This patch increases the schedule timeout to 10 jiffies, it's more
> appropriate, then other takes can easy to hold the mutex lock.
>
> Signed-off-by: Amos Kong
> ---
> drivers/char/hw_random/core.c | 2 +-
> 1 file changed, 1 insertion(+),
On Tue, 16 Sep 2014 00:02:27 +0800
Amos Kong wrote:
> It doesn't save too much cpu time as expected, just a cleanup.
>
> Signed-off-by: Amos Kong
> ---
> drivers/char/hw_random/core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c
I started a QEMU (non-smp) guest with one virtio-rng device, and read
random data from /dev/hwrng by dd:
# dd if=/dev/hwrng of=/dev/null &
In the same time, if I check hwrng attributes from sysfs by cat:
# cat /sys/class/misc/hw_random/rng_*
The cat process always gets stuck with slow backend
If we read hwrng by long-running dd process, it takes too much cpu
time and almost hold the mutex lock. When we check hwrng attributes
from sysfs by cat, it gets stuck in waiting the lock releaseing.
The problem can only be reproduced with non-smp guest with slow backend.
This patchset resolves th
This patch increases the schedule timeout to 10 jiffies, it's more
appropriate, then other takes can easy to hold the mutex lock.
Signed-off-by: Amos Kong
---
drivers/char/hw_random/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers
It doesn't save too much cpu time as expected, just a cleanup.
Signed-off-by: Amos Kong
---
drivers/char/hw_random/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25..c591d7e 100644
--- a/dr
Christoffer Dall writes:
> On Wed, Sep 10, 2014 at 11:34:53AM +0200, Paolo Bonzini wrote:
>> Il 09/09/2014 18:27, Alex Bennée ha scritto:
>> > Hi,
>> >
>> > I'm preparing to add ARM KVM GDB support and I went to read the API
>> > documentation and found it surprisingly mute on the subject ;-)
>>
> On September 15, 2014 at 12:48 PM Erik Rull wrote:
>
>
> > On September 12, 2014 at 7:29 PM Jan Kiszka wrote:
> >
> >
> > On 2014-09-12 19:15, Jan Kiszka wrote:
> > > On 2014-09-12 14:29, Erik Rull wrote:
> > >>> On September 11, 2014 at 3:32 PM Jan Kiszka
> > >>> wrote:
> > >>>
> > >>>
> > >>
> On September 12, 2014 at 7:29 PM Jan Kiszka wrote:
>
>
> On 2014-09-12 19:15, Jan Kiszka wrote:
> > On 2014-09-12 14:29, Erik Rull wrote:
> >>> On September 11, 2014 at 3:32 PM Jan Kiszka
> >>> wrote:
> >>>
> >>>
> >>> On 2014-09-11 15:25, Erik Rull wrote:
> > On August 6, 2014 at 1:19 PM E
Juan Quintela writes:
> Hi
>
> Please, send any topic that you are interested in covering.
>
> People have complained on the past that I don't cancel the call until
> the very last minute. So, what do you think that deadline for
> submitting topics is 23:00UTC on Monday?
Yes, please.
[...]
--
Hi
Please, send any topic that you are interested in covering.
People have complained on the past that I don't cancel the call until
the very last minute. So, what do you think that deadline for
submitting topics is 23:00UTC on Monday?
Call details:
15:00 CEST
13:00 UTC
09:00 EDT
Every
20 matches
Mail list logo
