Marcelo Tosatti wrote:
> On Thu, Feb 04, 2010 at 08:00:26PM +0100, Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Marcelo Tosatti wrote:
Unrelated to this problem, won't put_vcpu_events, which is executed
after KVM_SET_GUEST_DEBUG, overwrite any queued debug exceptions?
>>> Good point, SET_G
On Thu, Feb 04, 2010 at 08:00:26PM +0100, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Marcelo Tosatti wrote:
> >>
> >> Unrelated to this problem, won't put_vcpu_events, which is executed
> >> after KVM_SET_GUEST_DEBUG, overwrite any queued debug exceptions?
> >
> > Good point, SET_GUEST_DEBUG shoul
On Thu, Feb 04, 2010 at 08:21:08PM +0100, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Marcelo Tosatti wrote:
> >> With kvm-autotest the failure is not sporadic (and the above commit
> >> applied): with KVM_SET_GUEST_DEBUG in arch_put_regs all migration
> >> tests fail, without, all of them succeed.
On Thu, Feb 04, 2010 at 08:21:08PM +0100, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Marcelo Tosatti wrote:
> >> With kvm-autotest the failure is not sporadic (and the above commit
> >> applied): with KVM_SET_GUEST_DEBUG in arch_put_regs all migration
> >> tests fail, without, all of them succeed.
Jan Kiszka wrote:
> Marcelo Tosatti wrote:
>> With kvm-autotest the failure is not sporadic (and the above commit
>> applied): with KVM_SET_GUEST_DEBUG in arch_put_regs all migration
>> tests fail, without, all of them succeed.
>>
>> So env->kvm_guest_debug has been zeroed by cpu_x86_init, which
Jan Kiszka wrote:
> Marcelo Tosatti wrote:
>>
>> Unrelated to this problem, won't put_vcpu_events, which is executed
>> after KVM_SET_GUEST_DEBUG, overwrite any queued debug exceptions?
>
> Good point, SET_GUEST_DEBUG should be last in the writeback for that reason.
Actually, we no longer need t
Marcelo Tosatti wrote:
> On Thu, Feb 04, 2010 at 04:41:44PM +0100, Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Marcelo Tosatti wrote:
On Thu, Feb 04, 2010 at 01:33:50AM +0100, Jan Kiszka wrote:
> Marcelo Tosatti wrote:
>> On Wed, Feb 03, 2010 at 10:29:45PM +0100, Jan Kiszka wrote:
>
On Thu, Feb 04, 2010 at 04:41:44PM +0100, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Marcelo Tosatti wrote:
> >> On Thu, Feb 04, 2010 at 01:33:50AM +0100, Jan Kiszka wrote:
> >>> Marcelo Tosatti wrote:
> On Wed, Feb 03, 2010 at 10:29:45PM +0100, Jan Kiszka wrote:
> > So far we synchronized
Jan Kiszka wrote:
> Marcelo Tosatti wrote:
>> On Thu, Feb 04, 2010 at 01:33:50AM +0100, Jan Kiszka wrote:
>>> Marcelo Tosatti wrote:
On Wed, Feb 03, 2010 at 10:29:45PM +0100, Jan Kiszka wrote:
> So far we synchronized any dirty VCPU state back into the kernel before
> updating the gues
Marcelo Tosatti wrote:
> On Thu, Feb 04, 2010 at 01:33:50AM +0100, Jan Kiszka wrote:
>> Marcelo Tosatti wrote:
>>> On Wed, Feb 03, 2010 at 10:29:45PM +0100, Jan Kiszka wrote:
So far we synchronized any dirty VCPU state back into the kernel before
updating the guest debug state. This was a
On Thu, Feb 04, 2010 at 01:33:50AM +0100, Jan Kiszka wrote:
> Marcelo Tosatti wrote:
> > On Wed, Feb 03, 2010 at 10:29:45PM +0100, Jan Kiszka wrote:
> >> So far we synchronized any dirty VCPU state back into the kernel before
> >> updating the guest debug state. This was a tribute to a deficit in x
Marcelo Tosatti wrote:
> On Wed, Feb 03, 2010 at 10:29:45PM +0100, Jan Kiszka wrote:
>> So far we synchronized any dirty VCPU state back into the kernel before
>> updating the guest debug state. This was a tribute to a deficit in x86
>> kernels before 2.6.33. But as this is an arch-dependent issue,
On Wed, Feb 03, 2010 at 10:29:45PM +0100, Jan Kiszka wrote:
> So far we synchronized any dirty VCPU state back into the kernel before
> updating the guest debug state. This was a tribute to a deficit in x86
> kernels before 2.6.33. But as this is an arch-dependent issue, it is
> better handle in th
13 matches
Mail list logo