[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] invtsc + migration + TSC scaling
From: |
Radim Krčmář |
Subject: |
Re: [Qemu-devel] invtsc + migration + TSC scaling |
Date: |
Tue, 18 Oct 2016 15:36:20 +0200 |
2016-10-17 18:24+0200, Paolo Bonzini:
> On 17/10/2016 16:50, Radim Krčmář wrote:
>> 2016-10-17 07:47-0200, Marcelo Tosatti:
>>> On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote:
>>>> I have been wondering: should we allow live migration with the
>>>> invtsc flag enabled, if TSC scaling is available on the
>>>> destination?
>>>
>>> TSC scaling and invtsc flag, yes.
>>
>> Yes, if we have well synchronized time between hosts, then we might be
>> able to migrate with a TSC shift that cannot be perceived by the guest.
>>
>> Unless the VM also has a migratable assigned PCI device that uses ART,
>> because we have no protocol to update the setting of ART (in CPUID), so
>> we should keep migration forbidden then.
>
> We don't publish the ART leaf at all, do we?
Yes, it's a matter of time, though -- someone already asked for PTP in
guests, so we'll have to either provide a paravirtual host<->guest time
synchronization protocol that shares PTP from the host or let them use
assigned devices ...
>>> 1) Migration: to host with different TSC frequency.
>>
>> We shouldn't have done this even now when emulating anything newer than
>> Pentium 4, because those CPUs have constant TSC, which only lacks the
>> guarantee that it doesn't stop in deep C-states:
>
> Right, but:
>
>>> since Linux guests use kvmclock and Windows guests use Hyper-V
>>> enlightenment, it should be fine to disable 2).
>
> ... and 1 too.
Yes. We could stop exposing TSC then, because it should have no direct
users -- kvmclock can work even if TSC is not in CPUID, because we
paravirtualize it.
> We should also blacklist the TSC deadline timer when invtsc is not
> available.
True.
I was thinking that with Wanpeng's VMX preemption patches, we might not
need the TSC nor paravirtual deadline timer, the because performance of
LAPIC one-shot could be very similar.
- [Qemu-devel] invtsc + migration + TSC scaling, Eduardo Habkost, 2016/10/14
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Marcelo Tosatti, 2016/10/17
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Radim Krčmář, 2016/10/17
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Paolo Bonzini, 2016/10/17
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Eduardo Habkost, 2016/10/17
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Marcelo Tosatti, 2016/10/17
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Paolo Bonzini, 2016/10/18
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Radim Krčmář, 2016/10/18
- Re: [Qemu-devel] invtsc + migration + TSC scaling,
Radim Krčmář <=
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Radim Krčmář, 2016/10/18
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Marcelo Tosatti, 2016/10/17
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Radim Krčmář, 2016/10/18
- Re: [Qemu-devel] invtsc + migration + TSC scaling, Dr. David Alan Gilbert, 2016/10/18