On Thu, Jul 09, 2015 at 03:26:20PM +0100, Peter Maydell wrote:
> On 9 July 2015 at 15:17, Christoffer Dall 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 bac
On 9 July 2015 at 15:17, Christoffer Dall 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
>
> virtio_current_cpu_endian () at /root/src/qemu
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
> > wrote:
> > > As I understand it, the problem is that if we ever run a VCPU after
> > > reading the value, and write
On Thu, Jul 09, 2015 at 01:07:24PM +0100, Peter Maydell wrote:
> On 9 July 2015 at 13:05, Christoffer Dall 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 i
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, M
On 9 July 2015 at 13:05, Christoffer Dall 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
> VCPUs because they may have
On Thu, Jul 09, 2015 at 11:38:40AM +0100, Peter Maydell wrote:
> On 9 July 2015 at 11:22, Christoffer Dall 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 proba
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 wrote:
>>> On 08/07/15 17:06, Peter Maydell wrote:
I'd prefer it
On 9 July 2015 at 11:22, Christoffer Dall 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 mechanism, since
>> by a
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 wrote:
> > On 08/07/15 17:06, Peter Maydell wrote:
> >> I'd prefer it if somebody could investigate to see why QEMU
> >> is ac
On 8 July 2015 at 17:37, Marc Zyngier 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
> waiting for t
On 08/07/15 17:06, Peter Maydell wrote:
> On 8 July 2015 at 16:56, Marc Zyngier wrote:
>> On 29/06/15 18:37, Peter Maydell wrote:
>>> On 29 June 2015 at 18:20, Claudio Fontana
>>> wrote:
On 26.06.2015 06:49, Jan Kiszka wrote:
> QEMU has the concept of write-back levels: KVM_PUT_RUNTIME_
On 8 July 2015 at 16:56, Marc Zyngier wrote:
> On 29/06/15 18:37, Peter Maydell wrote:
>> On 29 June 2015 at 18:20, Claudio Fontana 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_ST
On 29/06/15 18:37, Peter Maydell wrote:
> On 29 June 2015 at 18:20, Claudio Fontana 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 int
On 29 June 2015 at 18:20, Claudio Fontana 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 written as part of
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
>>> wrote:
Once the VM is created, I think QEMU should not request kvm to
change the virtual offset of the VM a
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 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 QEM
On 25.06.2015 11:10, Peter Maydell wrote:
> On 25 June 2015 at 09:59, Claudio Fontana 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 target-arm/kvm64.c::kvm_arch_put_registers ?
>
On 25 June 2015 at 09:59, Claudio Fontana 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 target-arm/kvm64.c::kvm_arch_put_registers ?
Hmm. In general we assume that we can:
* stop
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 th
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
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 for
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 forward (best case) or backward (really bad idea). Either way,
this shoul
23 matches
Mail list logo
