On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org
wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the
On 9 July 2015 at 15:17, Christoffer Dall christoffer.d...@linaro.org wrote:
On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
So I ran this through GDB, and this happens when the guest probes the
virtio devices, specifically the backtrace tells me that
On Thu, Jul 09, 2015 at 03:26:20PM +0100, Peter Maydell wrote:
On 9 July 2015 at 15:17, Christoffer Dall christoffer.d...@linaro.org wrote:
On Thu, Jul 09, 2015 at 02:24:06PM +0200, Christoffer Dall wrote:
So I ran this through GDB, and this happens when the guest probes the
virtio devices,
On 9 July 2015 at 11:22, Christoffer Dall christoffer.d...@linaro.org wrote:
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
I suspect Jan is right and we really need to distinguish
the KVM_PUT_*_STATE levels in ARM QEMU. This probably
implies some kind of whitelist/override
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the value, and write back the value afterwards, you potentially
make time go backwards and get inconsistent views of time from different
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
On 9 July 2015 at 13:05, Christoffer Dall christoffer.d...@linaro.org wrote:
As I understand it, the problem is that if we ever run a VCPU after
reading the value, and write back the value afterwards, you potentially
make time
On Thu, Jul 09, 2015 at 11:38:40AM +0100, Peter Maydell wrote:
On 9 July 2015 at 11:22, Christoffer Dall christoffer.d...@linaro.org wrote:
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
I suspect Jan is right and we really need to distinguish
the KVM_PUT_*_STATE levels in
Hi Jan,
On Thu, Jul 09, 2015 at 12:40:39PM +0200, Jan Kiszka wrote:
On 2015-07-09 12:22, Christoffer Dall wrote:
Hi Peter and Marc,
[cc'ing Paolo for his input on x86 timekeeping]
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
On 8 July 2015 at 17:37, Marc Zyngier
Hi Peter and Marc,
[cc'ing Paolo for his input on x86 timekeeping]
On Wed, Jul 08, 2015 at 08:13:59PM +0100, Peter Maydell wrote:
On 8 July 2015 at 17:37, Marc Zyngier marc.zyng...@arm.com wrote:
On 08/07/15 17:06, Peter Maydell wrote:
I'd prefer it if somebody could investigate to see why
On 8 July 2015 at 16:56, Marc Zyngier marc.zyng...@arm.com wrote:
On 29/06/15 18:37, Peter Maydell wrote:
On 29 June 2015 at 18:20, Claudio Fontana claudio.font...@huawei.com wrote:
On 26.06.2015 06:49, Jan Kiszka wrote:
QEMU has the concept of write-back levels: KVM_PUT_RUNTIME_STATE,
On 08/07/15 17:06, Peter Maydell wrote:
On 8 July 2015 at 16:56, Marc Zyngier marc.zyng...@arm.com wrote:
On 29/06/15 18:37, Peter Maydell wrote:
On 29 June 2015 at 18:20, Claudio Fontana claudio.font...@huawei.com
wrote:
On 26.06.2015 06:49, Jan Kiszka wrote:
QEMU has the concept of
On 8 July 2015 at 17:37, Marc Zyngier marc.zyng...@arm.com wrote:
On 08/07/15 17:06, Peter Maydell wrote:
I'd prefer it if somebody could investigate to see why QEMU
is actually doing this -- so far we just have speculation.
I'd prefer that too, but so far people seem to be more comfortable
On 26.06.2015 06:49, Jan Kiszka wrote:
On 2015-06-25 11:25, Claudio Fontana wrote:
On 25.06.2015 11:10, Peter Maydell wrote:
On 25 June 2015 at 09:59, Claudio Fontana claudio.font...@huawei.com
wrote:
Once the VM is created, I think QEMU should not request kvm to
change the virtual offset
On 29 June 2015 at 18:20, Claudio Fontana claudio.font...@huawei.com wrote:
On 26.06.2015 06:49, Jan Kiszka wrote:
QEMU has the concept of write-back levels: KVM_PUT_RUNTIME_STATE,
KVM_PUT_RESET_STATE and KVM_PUT_FULL_STATE. I suspect this registers is
just sorted into the wrong category, thus
On Wed, Jun 24, 2015 at 03:54:57PM +0100, Marc Zyngier wrote:
Userspace is allowed to set the guest's view of CNTVCT, which turns
into setting CNTVOFF for the whole VM. One thing userspace is not supposed
to do is to update that register while the guest is running. Time will
either move
On 2015-06-25 11:25, Claudio Fontana wrote:
On 25.06.2015 11:10, Peter Maydell wrote:
On 25 June 2015 at 09:59, Claudio Fontana claudio.font...@huawei.com wrote:
Once the VM is created, I think QEMU should not request kvm to
change the virtual offset of the VM anymore: maybe an unexpected
Hi Christoffer,
On 25/06/15 09:04, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 03:54:57PM +0100, Marc Zyngier wrote:
Userspace is allowed to set the guest's view of CNTVCT, which turns
into setting CNTVOFF for the whole VM. One thing userspace is not supposed
to do is to update that
Hi Christoffer,
On 25.06.2015 10:04, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 03:54:57PM +0100, Marc Zyngier wrote:
Userspace is allowed to set the guest's view of CNTVCT, which turns
into setting CNTVOFF for the whole VM. One thing userspace is not supposed
to do is to update that
On 25.06.2015 11:10, Peter Maydell wrote:
On 25 June 2015 at 09:59, Claudio Fontana claudio.font...@huawei.com wrote:
Once the VM is created, I think QEMU should not request kvm to
change the virtual offset of the VM anymore: maybe an unexpected
consequence of QEMU's
19 matches
Mail list logo
