On Mon, Jan 20, 2014 at 10:07:47PM +0100, Andreas Färber wrote:
> Am 20.01.2014 21:39, schrieb Michael S. Tsirkin:
> > On Mon, Jan 20, 2014 at 04:36:56PM -0200, Eduardo Habkost wrote:
> >> On Mon, Jan 20, 2014 at 02:41:07PM -0200, Eduardo Habkost wrote:
> >>> Resend of series submitted on 24 Novemb
Am 20.01.2014 21:39, schrieb Michael S. Tsirkin:
> On Mon, Jan 20, 2014 at 04:36:56PM -0200, Eduardo Habkost wrote:
>> On Mon, Jan 20, 2014 at 02:41:07PM -0200, Eduardo Habkost wrote:
>>> Resend of series submitted on 24 November 2013, that didn't get any reply.
>>> Only
>>> change is a trivial co
On Mon, Jan 20, 2014 at 04:36:56PM -0200, Eduardo Habkost wrote:
> On Mon, Jan 20, 2014 at 02:41:07PM -0200, Eduardo Habkost wrote:
> > Resend of series submitted on 24 November 2013, that didn't get any reply.
> > Only
> > change is a trivial conflict on patch 7/7.
>
> Question: which tree is th
On Mon, Jan 20, 2014 at 03:22:11PM +0100, Alexander Graf wrote:
>
> On 17.01.2014, at 19:52, Peter Maydell wrote:
>
> > On 17 January 2014 17:53, Peter Maydell wrote:
> >> Specifically, the KVM API says "here's a uint8_t[] byte
> >> array and a length", and the current QEMU code treats that
> >
On Mon, Jan 20, 2014 at 02:41:07PM -0200, Eduardo Habkost wrote:
> Resend of series submitted on 24 November 2013, that didn't get any reply.
> Only
> change is a trivial conflict on patch 7/7.
Question: which tree is the most appropriate to get this in? qom-cpu?
kvm?
>
> This series simplifie
Hi Marc,
On Mon, Jan 20, 2014 at 7:11 PM, Marc Zyngier wrote:
> Hi Anup,
>
> On 20/01/14 12:00, Anup Patel wrote:
>> On Fri, Jan 17, 2014 at 8:33 PM, Marc Zyngier wrote:
>>> In order to be able to detect the point where the guest enables
>>> its MMU and caches, trap all the VM related system reg
On 10.01.2014, at 02:18, Scott Wood wrote:
> Simplify the handling of lazy EE by going directly from fully-enabled
> to hard-disabled. This replaces the lazy_irq_pending() check
> (including its misplaced kvm_guest_exit() call).
>
> As suggested by Tiejun Chen, move the interrupt disabling int
(2014/01/20 22:33), Marcelo Tosatti wrote:
On Mon, Jan 20, 2014 at 11:56:56AM +0200, Nadav Har'El wrote:
If KVM_SYSTEM_TIME is not a correct way to get a monotonic paravirtual clock
from KVM, is there a correct way?
Inside a Linux guest? Can use sched_clock().
I would like to mention that Lin
On Mon, 20 Jan 2014 12:43:45 +1030
Rusty Russell wrote:
> Luiz Capitulino writes:
> > On Fri, 17 Jan 2014 09:10:47 +1030
> > Rusty Russell wrote:
> >
> >> Luiz Capitulino writes:
> >> > From: Luiz capitulino
> >> >
> >> > This commit adds support to a new virtqueue called message virtqueue.
>
> You also aren't describing if doing anything specifically will cause the
> crash.
Sorry, I've yet to narrow down the exact case that's causing it. Basically,
it's constant use of the vm-channel; I have a binary that will write to the
character device at an interval. If I leave it running wit
Il 12/12/2013 12:09, Liu, Jinsong ha scritto:
> Paolo Bonzini wrote:
>> Il 12/12/2013 06:47, Liu, Jinsong ha scritto:
>>> Paolo Bonzini wrote:
Il 11/12/2013 09:31, Liu, Jinsong ha scritto:
> Paolo, comments for version 2?
I think I commented that it's fine, I'm just waiting for a
On 20 January 2014 14:20, Alexander Graf wrote:
> I think I see the problem now. You're thinking about LE hosts, not LE guests.
>
> I think the only really sensible options would be to
>
> a) Always use a statically define target endianness (big for ppc)
> b) Always use host endianness
> Curr
On 17.01.2014, at 19:52, Peter Maydell wrote:
> On 17 January 2014 17:53, Peter Maydell wrote:
>> Specifically, the KVM API says "here's a uint8_t[] byte
>> array and a length", and the current QEMU code treats that
>> as "this is a byte array written as if the guest CPU
>> (a) were in TARGET_W
On 18.01.2014, at 11:15, Peter Maydell wrote:
> On 18 January 2014 07:32, Alexander Graf wrote:
>>> Am 18.01.2014 um 05:24 schrieb Christoffer Dall
>>> :
On Fri, Jan 17, 2014 at 06:52:57PM +, Peter Maydell wrote:
Having thought a little more about this, my opinion is:
Il 20/01/2014 13:37, Wesley Holevinski ha scritto:
>
> Hi all,
>
> I'm running into an issue that's causing my guests to crash while
> using vm-channels. There is an assertion that's failing in qemu-char.c,
> that, when it happens causes my guest to go down. The error can be seen
> in the host-si
On Mon, Jan 20, 2014 at 11:56:56AM +0200, Nadav Har'El wrote:
> Hi,
>
> I'm trying to figure out how a guest OS can get a monotonic clock using
> KVM's paravirtual clock.
>
> At first, I thought that the clock I get using KVM_SYSTEM_TIME is a
> monotonic clock, based on the host's monotonic clock
Hi Anup,
On 20/01/14 12:00, Anup Patel wrote:
> On Fri, Jan 17, 2014 at 8:33 PM, Marc Zyngier wrote:
>> In order to be able to detect the point where the guest enables
>> its MMU and caches, trap all the VM related system registers.
>>
>> Once we see the guest enabling both the MMU and the caches
The original patch from Liu Jinsong restricted them to reset or full
state updates, but that's unnecessary (and wrong) since the BNDCFGS
MSR has no side effects.
Cc: Liu Jinsong
Signed-off-by: Paolo Bonzini
---
target-i386/kvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Hi all,
I'm running into an issue that's causing my guests to crash while using
vm-channels. There is an assertion that's failing in qemu-char.c, that, when
it happens causes my guest to go down. The error can be seen in the host-side
logs.
Rather than being too wordy on-list, here's a link
On Fri, Jan 17, 2014 at 8:33 PM, Marc Zyngier wrote:
> In order to be able to detect the point where the guest enables
> its MMU and caches, trap all the VM related system registers.
>
> Once we see the guest enabling both the MMU and the caches, we
> can go back to a saner mode of operation, whic
On Mon, 20 Jan 2014 12:54:03 +0100
Christian Borntraeger wrote:
> Seems that commit 210b1607012cc9034841a393e0591b2c86d9e26c
> (KVM: s390: Removed SIE_INTERCEPT_UCONTROL) lost a hunk when we
> reworked our patch queue to rework the async_fp code. We now
> ignore faults on the sie instruction (gue
Il 20/01/2014 12:54, Christian Borntraeger ha scritto:
> Paolo,
>
> here is a fix for a regression that is in current kvm/next, which is
> targetted for 3.14. Please apply
>
> Christian Borntraeger (1):
> KVM: s390: Fix memory access error detection
>
> arch/s390/kvm/kvm-s390.c |4
>
Paolo,
here is a fix for a regression that is in current kvm/next, which is
targetted for 3.14. Please apply
Christian Borntraeger (1):
KVM: s390: Fix memory access error detection
arch/s390/kvm/kvm-s390.c |4
1 file changed, 4 insertions(+)
--
1.7.9.5
The following changes since
Seems that commit 210b1607012cc9034841a393e0591b2c86d9e26c
(KVM: s390: Removed SIE_INTERCEPT_UCONTROL) lost a hunk when we
reworked our patch queue to rework the async_fp code. We now
ignore faults on the sie instruction (guest accesses non-existing
memory) instead of sending a fault into the guest
Hi,
I'm trying to figure out how a guest OS can get a monotonic clock using
KVM's paravirtual clock.
At first, I thought that the clock I get using KVM_SYSTEM_TIME is a
monotonic clock, based on the host's monotonic clock.
But I'm no longer sure this is actually done correctly:
1. What happens o
25 matches
Mail list logo
