On 12/09/2013 05:50 PM, Fernando Luis Vázquez Cao wrote:
On 12/06/2013 11:22 PM, Marcelo Tosatti wrote:
On Fri, Dec 06, 2013 at 05:24:18PM +0900, Fernando Luis Vázquez Cao
wrote:
I also wanted to make sure that the initialization that we do
in kvm_arch_vcpu_postcreate on power up and the
On 12/06/2013 11:22 PM, Marcelo Tosatti wrote:
On Fri, Dec 06, 2013 at 05:24:18PM +0900, Fernando Luis Vázquez Cao wrote:
I also wanted to make sure that the initialization that we do
in kvm_arch_vcpu_postcreate on power up and the subsequent
TSC writeback work well together, but I didn't
On 12/06/2013 05:36 PM, Paolo Bonzini wrote:
Il 06/12/2013 09:24, Fernando Luis Vázquez Cao ha scritto:
Could we start with the patch that I already sent? It's been
tested, it is conservative in the sense that it does the minimum
necessary to fix an existing bug, and should be easy to
bac
Newer kernels are capable of synchronizing TSC values of multiple VCPUs
on writeback, but we were excluding the power up case, which is not needed
anymore.
Signed-off-by: Fernando Luis Vazquez Cao
---
diff -urNp qemu-orig/target-i386/kvm.c qemu/target-i386/kvm.c
--- qemu-orig/target-i386/kvm.c 2
VCPU TSC is not cleared by a warm reset (*), which leaves some types of Linux
guests (non-pvops guests and those with the kernel parameter no-kvmclock set)
vulnerable to the overflow in cyc2ns_offset fixed by upstream commit
9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 ("sched/x86: Fix overflow in
cyc
On 12/06/2013 01:38 AM, Paolo Bonzini wrote:
Il 05/12/2013 17:17, Marcelo Tosatti ha scritto:
I agree it is a bit ugly, but in my testing QEMU seemed to loop over all
the VCPUS fast enough for the kernel side kvm_write_tsc() to do a
reasonable job of matching the offsets (the Linux guest did not
VCPU TSC is not cleared by a warm reset (*), which leaves many Linux
guests vulnerable to the overflow in cyc2ns_offset fixed by upstream
commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 ("sched/x86: Fix overflow
in cyc2ns_offset").
To put it in a nutshell, if a Linux guest without the patch above
I realized that the TSC reset should be done in QEMU
so I will be replying with a QEMU patch instead of a
KVM one.
- Fernando
On 12/03/2013 05:04 PM, Fernando Luis Vázquez Cao wrote:
I think there is a problem with the current patch, so please
ignore for the moment. I will be replying with an
On 02/03/2012 11:16 AM, Fernando Luis Vázquez Cao wrote:
On 02/02/2012 07:11 AM, Anthony Liguori wrote:
On 01/29/2012 08:17 PM, Fernando Luis Vázquez Cao wrote:
Some drivers (Linux' 8139too among them) rely on the NIC injecting
an interrupt
in the event of a receive buffer overflo
On 02/02/2012 07:11 AM, Anthony Liguori wrote:
On 01/29/2012 08:17 PM, Fernando Luis Vázquez Cao wrote:
Some drivers (Linux' 8139too among them) rely on the NIC injecting an
interrupt
in the event of a receive buffer overflow and, accordingly, set the
RxOverflow
bit in the interrupt
(2012年01月31日 13:12), Igor Kovalenko wrote:
2012/1/30 Fernando Luis Vázquez Cao:
Some drivers (Linux' 8139too among them) rely on the NIC injecting an interrupt
in the event of a receive buffer overflow and, accordingly, set the RxOverflow
bit in the interrupt mask. Unfortunately rtl8
Hi Igor,
Thank you for the prompt reply. I really appreciate it.
(2012年01月31日 02:28), Igor Kovalenko wrote:
2012/1/30 Fernando Luis Vázquez Cao:
Some drivers (Linux' 8139too among them) rely on the NIC injecting an interrupt
in the event of a receive buffer overflow and, accordingly, se
Some drivers (Linux' 8139too among them) rely on the NIC injecting an interrupt
in the event of a receive buffer overflow and, accordingly, set the RxOverflow
bit in the interrupt mask. Unfortunately rtl8139's can_receive method ignores
the RxOverflow flag, which may lead to a situation where rtl81
On Wed, 2011-07-27 at 17:24 +0200, Andrea Arcangeli wrote:
> making
> sure no lib is calling any I/O function to be able to defreeze the
> filesystems later, making sure the oom killer or a wrong kill -9
> $RANDOM isn't killing the agent by mistake while the I/O is blocked
> and the copy is going.
On 04/23/2010 02:17 PM, Yoshiaki Tamura wrote:
> Dor Laor wrote:
[...]
>> Second, even if it wasn't the case, the tsc delta and kvmclock are
>> synchronized as part of the VM state so there is no use of trapping it
>> in the middle.
>
> I should study the clock in KVM, but won't tsc get updated by
Avi Kivity wrote:
On 11/09/2009 05:53 AM, Fernando Luis Vázquez Cao wrote:
Kemari runs paired virtual machines in an active-passive configuration
and achieves whole-system replication by continuously copying the
state of the system (dirty pages and the state of the virtual devices)
from the
Hi all,
It has been a while coming, but we have finally started work on
Kemari's port to KVM. For those not familiar with it, Kemari provides
the basic building block to create a virtualization-based fault
tolerant machine: a virtual machine synchronization mechanism.
Traditional high availabili
17 matches
Mail list logo
