On 11/04/2019 08:27, Heyi Guo wrote:
> Hi Steve,
>
> After reading kernel code about time keeping and something related, I've
> not got a clear picture of how we can use MSR_KVM_WALL_CLOCK_NEW to keep
> wall clock in guest VM.
>
> 1. On X86, MSR_KVM_WALL_CLOCK_NEW is only used by the callback of
Hi Steve,
After reading kernel code about time keeping and something related, I've not
got a clear picture of how we can use MSR_KVM_WALL_CLOCK_NEW to keep wall clock
in guest VM.
1. On X86, MSR_KVM_WALL_CLOCK_NEW is only used by the callback of system
suspend and resume; I didn't find it
Hi Heyi,
On 26/03/2019 13:53, Heyi Guo wrote:
> I also tested save/restore operations, and observed that clock in guest
> would not jump after restoring either. If we consider guest clock not
> being synchronized with real wall clock as an issue, does it mean
> save/restore function has the same
I also tested save/restore operations, and observed that clock in guest would
not jump after restoring either. If we consider guest clock not being
synchronized with real wall clock as an issue, does it mean save/restore
function has the same issue?
Thanks,
Heyi
On 2019/3/26 19:54, Heyi
Hi Steven,
Thanks for your explanation. Please see my comments below.
On 2019/3/21 0:29, Steven Price wrote:
On 19/03/2019 14:39, Heyi Guo wrote:
Hi Christoffer and Steve,
On 2019/3/15 16:59, Christoffer Dall wrote:
Hi Steve,
On Wed, Mar 13, 2019 at 10:11:30AM +, Steven Price wrote:
On 19/03/2019 14:39, Heyi Guo wrote:
> Hi Christoffer and Steve,
>
>
> On 2019/3/15 16:59, Christoffer Dall wrote:
>> Hi Steve,
>>
>> On Wed, Mar 13, 2019 at 10:11:30AM +, Steven Price wrote:
>>> Personally I think what we need is:
>>>
>>> * Either a patch like the one from Heyi Guo
Hi Christoffer and Steve,
On 2019/3/15 16:59, Christoffer Dall wrote:
Hi Steve,
On Wed, Mar 13, 2019 at 10:11:30AM +, Steven Price wrote:
Personally I think what we need is:
* Either a patch like the one from Heyi Guo (save/restore CNTVCT_EL0) or
alternatively hooking up
Hi Steve,
On Wed, Mar 13, 2019 at 10:11:30AM +, Steven Price wrote:
>
> Personally I think what we need is:
>
> * Either a patch like the one from Heyi Guo (save/restore CNTVCT_EL0) or
> alternatively hooking up KVM_KVMCLOCK_CTRL to prevent the watchdog
> firing when user space explicitly
Hi Peter and Steven,
On 2019/3/13 18:11, Steven Price wrote:
On 12/03/2019 14:12, Marc Zyngier wrote:
Hi Peter,
On 12/03/2019 10:08, Peter Maydell wrote:
On Tue, 12 Mar 2019 at 06:10, Heyi Guo wrote:
When we stop a VM for more than 30 seconds and then resume it, by qemu
monitor command
On 12/03/2019 14:12, Marc Zyngier wrote:
> Hi Peter,
>
> On 12/03/2019 10:08, Peter Maydell wrote:
>> On Tue, 12 Mar 2019 at 06:10, Heyi Guo wrote:
>>>
>>> When we stop a VM for more than 30 seconds and then resume it, by qemu
>>> monitor command "stop" and "cont", Linux on VM will complain of
On 13/03/2019 01:57, Heyi Guo wrote:
> Dear all,
>
> Really appreciate your comments and information. For "Live Physical
> Time", is there any document to tell the whole story? And may I know the
> timeline to make it happen?
The documentation is available here:
Dear all,
Really appreciate your comments and information. For "Live Physical Time", is
there any document to tell the whole story? And may I know the timeline to make it happen?
Thanks,
Heyi
On 2019/3/12 22:12, Marc Zyngier wrote:
Hi Peter,
On 12/03/2019 10:08, Peter Maydell wrote:
On
Hi Richard,
On 2019/3/12 22:59, Richard Henderson wrote:
On 3/12/19 12:57 AM, Heyi Guo wrote:
int kvm_arm_vcpu_init(CPUState *cs)
{
ARMCPU *cpu = ARM_CPU(cs);
struct kvm_vcpu_init init;
+/*
+ * Only add change state handler for arch timer once, for KVM will help
On 3/12/19 12:57 AM, Heyi Guo wrote:
> int kvm_arm_vcpu_init(CPUState *cs)
> {
> ARMCPU *cpu = ARM_CPU(cs);
> struct kvm_vcpu_init init;
>
> +/*
> + * Only add change state handler for arch timer once, for KVM will help
> to
> + * synchronize virtual timer of all VCPUs.
Hi Peter,
On 12/03/2019 10:08, Peter Maydell wrote:
> On Tue, 12 Mar 2019 at 06:10, Heyi Guo wrote:
>>
>> When we stop a VM for more than 30 seconds and then resume it, by qemu
>> monitor command "stop" and "cont", Linux on VM will complain of "soft
>> lockup - CPU#x stuck for xxs!" as below:
>>
[Adding Steven Price, who has recently looked at this, in cc]
On Tue, Mar 12, 2019 at 10:08:47AM +, Peter Maydell wrote:
> On Tue, 12 Mar 2019 at 06:10, Heyi Guo wrote:
> >
> > When we stop a VM for more than 30 seconds and then resume it, by qemu
> > monitor command "stop" and "cont", Linux
On Tue, 12 Mar 2019 at 06:10, Heyi Guo wrote:
>
> When we stop a VM for more than 30 seconds and then resume it, by qemu
> monitor command "stop" and "cont", Linux on VM will complain of "soft
> lockup - CPU#x stuck for xxs!" as below:
>
> [ 2783.809517] watchdog: BUG: soft lockup - CPU#3 stuck
Hi all,
I'm sorry this patch failed the docker-mingw@fedora build test. I'm going to
move the code to target/arm/kvm.c.
Please ignore this one.
Thanks,
Heyi
On 2019/3/12 14:09, Heyi Guo wrote:
When we stop a VM for more than 30 seconds and then resume it, by qemu
monitor command "stop"
When we stop a VM for more than 30 seconds and then resume it, by qemu
monitor command "stop" and "cont", Linux on VM will complain of "soft
lockup - CPU#x stuck for xxs!" as below:
[ 2783.809517] watchdog: BUG: soft lockup - CPU#3 stuck for 2395s!
[ 2783.809559] watchdog: BUG: soft lockup -
Patchew URL:
https://patchew.org/QEMU/1552370960-2061-1-git-send-email-guoh...@huawei.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
When we stop a VM for more than 30 seconds and then resume it, by qemu
monitor command "stop" and "cont", Linux on VM will complain of "soft
lockup - CPU#x stuck for xxs!" as below:
[ 2783.809517] watchdog: BUG: soft lockup - CPU#3 stuck for 2395s!
[ 2783.809559] watchdog: BUG: soft lockup -
21 matches
Mail list logo
