Sanjay Lal wrote on 2013-03-02:
> The following patchset implements KVM support for MIPS32 processors,
> using Trap & Emulate, with basic runtime binary translation to improve
> performance.
>
> In KVM mode, CPU virtualization is handled via the kvm kernel module,
> while system and I/O virtualiza
Gleb Natapov wrote on 2012-11-22:
> On Wed, Nov 21, 2012 at 04:09:38PM +0800, Yang Zhang wrote:
>> Ack interrupt on vmexit is required by Posted Interrupt. With it,
>> when external interrupt caused vmexit, the cpu will acknowledge the
>> interrupt controller and save the interrupt's vector in vmcs
Gleb Natapov wrote on 2012-11-22:
> On Wed, Nov 21, 2012 at 04:09:36PM +0800, Yang Zhang wrote:
>> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
>> manually, which is fully taken care of by the hardware. This needs
>> some special awareness into existing interrupr injection path:
Gleb Natapov wrote on 2012-11-25:
> On Wed, Nov 21, 2012 at 04:09:39PM +0800, Yang Zhang wrote:
>> Posted Interrupt allows vAPICV interrupts to inject into guest directly
>> without any vmexit.
>>
>> - When delivering a interrupt to guest, if target vcpu is running,
>> update Posted-interrupt re
Avi Kivity wrote on 2012-11-25:
> On 11/25/2012 03:03 PM, Gleb Natapov wrote:
>> On Sun, Nov 25, 2012 at 02:55:26PM +0200, Avi Kivity wrote:
>>> On 11/22/2012 05:22 PM, Gleb Natapov wrote:
On Wed, Nov 21, 2012 at 04:09:38PM +0800, Yang Zhang wrote:
> Ack interrupt on vmexit is required by
Gleb Natapov wrote on 2012-11-26:
> On Mon, Nov 26, 2012 at 03:51:04AM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-11-25:
>>> On Wed, Nov 21, 2012 at 04:09:39PM +0800, Yang Zhang wrote:
>>>> Posted Interrupt allows vAPICV interrupts to inject into g
Gleb Natapov wrote on 2012-11-26:
> On Mon, Nov 26, 2012 at 12:29:54PM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-11-26:
>>> On Mon, Nov 26, 2012 at 03:51:04AM +, Zhang, Yang Z wrote:
>>>> Gleb Natapov wrote on 2012-11-25:
>>>>> O
Gleb Natapov wrote on 2012-11-27:
> On Tue, Nov 27, 2012 at 03:38:05AM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-11-26:
>>> On Mon, Nov 26, 2012 at 12:29:54PM +, Zhang, Yang Z wrote:
>>>> Gleb Natapov wrote on 2012-11-26:
>>>>> On
Gleb Natapov wrote on 2012-12-03:
> On Mon, Dec 03, 2012 at 03:01:01PM +0800, Yang Zhang wrote:
>> When PIT connects to IOAPIC, it route to pin 2 not pin 0.
>>
> This hack didn't work for a long time and nobody complained. It
> should be safe to get rid of it.
This hack is used to work around an i
Gleb Natapov wrote on 2012-12-03:
> On Mon, Dec 03, 2012 at 03:01:03PM +0800, Yang Zhang wrote:
>> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
>> manually, which is fully taken care of by the hardware. This needs
>> some special awareness into existing interrupr injection path:
Gleb Natapov wrote on 2012-12-04:
> On Tue, Dec 04, 2012 at 05:32:31AM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-12-03:
>>> On Mon, Dec 03, 2012 at 03:01:01PM +0800, Yang Zhang wrote:
>>>> When PIT connects to IOAPIC, it route to pin 2 not pin 0.
>&
Gleb Natapov wrote on 2012-12-04:
> On Tue, Dec 04, 2012 at 06:39:50AM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-12-03:
>>> On Mon, Dec 03, 2012 at 03:01:03PM +0800, Yang Zhang wrote:
>>>> Virtual interrupt delivery avoids KVM to inject vAPIC inte
Marcelo Tosatti wrote on 2012-12-05:
> On Mon, Dec 03, 2012 at 03:01:02PM +0800, Yang Zhang wrote:
>> - APIC read doesn't cause VM-Exit
>> - APIC write becomes trap-like
>>
>> Signed-off-by: Yang Zhang
>> Signed-off-by: Kevin Tian
>> ---
>> arch/x86/include/asm/vmx.h |2 ++ arch/x86/kvm/lapi
Marcelo Tosatti wrote on 2012-12-05:
> On Mon, Dec 03, 2012 at 03:01:03PM +0800, Yang Zhang wrote:
>> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
>> manually, which is fully taken care of by the hardware. This needs
>> some special awareness into existing interrupr injection pa
Gleb Natapov wrote on 2012-12-05:
> On Wed, Dec 05, 2012 at 01:55:17AM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-12-04:
>>> On Tue, Dec 04, 2012 at 06:39:50AM +, Zhang, Yang Z wrote:
>>>> Gleb Natapov wrote on 2012-12-03:
>>>>> O
Gleb Natapov wrote on 2012-12-05:
> On Wed, Dec 05, 2012 at 06:02:59AM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-12-05:
>>> On Wed, Dec 05, 2012 at 01:55:17AM +, Zhang, Yang Z wrote:
>>>> Gleb Natapov wrote on 2012-12-04:
>>>>> On
Gleb Natapov wrote on 2012-12-05:
> On Wed, Dec 05, 2012 at 03:43:41AM +0000, Zhang, Yang Z wrote:
>>>> @@ -5657,12 +5673,20 @@ static int vcpu_enter_guest(struct kvm_vcpu
>>> *vcpu)
>>>>}
>>>>
>>>>if (kvm_check_request(KVM_
Gleb Natapov wrote on 2012-12-05:
> On Wed, Dec 05, 2012 at 01:51:36PM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-12-05:
>>> On Wed, Dec 05, 2012 at 06:02:59AM +, Zhang, Yang Z wrote:
>>>> Gleb Natapov wrote on 2012-12-05:
>>>>> On
Gleb Natapov wrote on 2012-12-05:
> On Wed, Dec 05, 2012 at 02:16:52PM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2012-12-05:
>>> On Wed, Dec 05, 2012 at 03:43:41AM +, Zhang, Yang Z wrote:
>>>>>> @@ -5657,12 +5673,20 @@ static int vcpu_ent
Marcelo Tosatti wrote on 2012-12-06:
> On Mon, Dec 03, 2012 at 03:01:03PM +0800, Yang Zhang wrote:
>> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
>> manually, which is fully taken care of by the hardware. This needs
>> some special awareness into existing interrupr injection pa
Zhang, Yang Z wrote on 2012-12-06:
> Marcelo Tosatti wrote on 2012-12-06:
>> On Mon, Dec 03, 2012 at 03:01:03PM +0800, Yang Zhang wrote:
>>> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
>>> manually, which is fully taken care of by the hardware.
Gleb Natapov wrote on 2012-12-06:
> On Thu, Dec 06, 2012 at 05:02:15AM +0000, Zhang, Yang Z wrote:
>> Zhang, Yang Z wrote on 2012-12-06:
>>> Marcelo Tosatti wrote on 2012-12-06:
>>>> On Mon, Dec 03, 2012 at 03:01:03PM +0800, Yang Zhang wrote:
>>>>> Vi
use int64 when compare two time
int32 only represent only 136 years when comparing two times based on second.
It would be better to use int64.
Signed-off-by: Yang Zhang
diff --git a/qemu-common.h b/qemu-common.h
index b2de015..c14f506 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -116,8 +1
Recently, I did some work for power optimization w/ KVM and I found
there was a periodic timer from qemu which stop the platform from staying deep
C state for a long period. After looking into the qemu code, there was a
periodic RTC update timer which is the culprit. In current RTC emula
use gettimeofday() instead of time().
Please refer the patch zero for the description.
Signed-off-by: Yang Zhang
diff --git a/vl.c b/vl.c
index 01c5a9d..9a51047 100644
--- a/vl.c
+++ b/vl.c
@@ -438,8 +438,11 @@ void qemu_get_timedate(struct tm *tm, int64_t offset)
{
time_t ti;
struct
change the RTC update logic to use host time with offset to calculate RTC clock.
There have no need to use two periodic timers to maintain an internal
timer for RTC clock update and alarm check. Instead, we calculate the real RTC
time by the host time with an offset. For alarm and updated
> -Original Message-
> From: Jan Kiszka [mailto:jan.kis...@web.de]
> Sent: Saturday, January 07, 2012 1:27 AM
> However, not having looked at details yet, two things jumped at me:
> - You cannot simply change the vmstate format without caring about
>migration from older qemu versions.
> -Original Message-
> From: Andreas Färber [mailto:afaer...@suse.de]
> Sent: Saturday, January 07, 2012 1:44 AM
> > use int64 when compare two time
> >
> > int32 only represent only 136 years when comparing two times based on
> second. It would be better to use int64.
>
> int32 and int64
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, January 09, 2012 4:19 PM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; a...@redhat.com; aligu...@us.ibm.com; Zhang,
> Xiantao; Shan, Haitao
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, January 10, 2012 5:25 PM
> >> Also, I'm not sure if the update in progress flag still works.
> >> Clients are supposed to wait for UIP=0 before reading the RTC, and an
> >> update is supposed to be at l
> -Original Message-
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
>
> Regarding the UIP bit, a guest could read it in a loop and wait for the value
> to
> change. But you can emulate it in cmos_ioport_read by reading the host time,
> that is, return 1 during 244us, 0 for remaining
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Because it's not in the spec because some engineer thought it was cool.
It not cool. We need to do some optimizations to get Better Performance.
> It's in the spec because it gives y
> -Original Message-
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Thursday, January 12, 2012 6:03 PM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; a...@redhat.com; aligu...@us.ibm.com; Zhang,
> Xiantao; Shan, Haitao; kvm@vger.kernel.org
> Subject:
Changes in v2:
Add UIP check logic.
Add logic that next second tick will occur in exactly 500ms later after setting
the clock
Current RTC emulation uses periodic timer(2 timers per second) to update RTC
clock. And it will stop CPU staying at deep C-state for long period. Our
experience shows th
There has no need to use two periodic timer to update RTC time.
In this patch, we only update it when guest reading it.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 199 +++---
1 files changed, 56 insertions(+), 143 deletions(-)
diff --git a
Use timer to emulate alarm. The timer is enabled when AIE is setting
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 187 ++
1 files changed, 187 insertions(+), 0 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index bb1873b..
Use timer to emulate RTC update-ended interrupt. The timer is enabled
only when UIE is setting.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 53 -
1 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc14
The UIP(update in progress) is set when RTC is updating. We only
consider the normal oscillator(32Khz) mode.
When time base is 32kHz, the update cycle takes 1984us at the end
of every second. And the update cycle begins 244us later after UIP
is set. So the UIP is set in 2228us at end of every seco
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, February 20, 2012 3:38 PM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; Jan Kiszka; kvm@vger.kernel.org;
> aligu...@us.ibm.com; Marcelo Tosatti
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Monday, February 20, 2012 3:41 PM
>
> On 02/20/2012 01:24 AM, Zhang, Yang Z wrote:
> > Changes in v2:
> > Add UIP check logic.
> > Add logic
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, February 22, 2012 7:19 PM
>
> 0) My alarm tests failed quite badly. :( I attach a patch for kvm-unit-tests
> (repository at git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git).
> The tests can
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, February 22, 2012 7:19 PM
> 0) My alarm tests failed quite badly. :( I attach a patch for kvm-unit-tests
> (repository at git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git).
> The tests can be
Changes in v3:
Rebase to latest head.
Remove the logic to update time format when DM bit changed.
Allow to migrate from old version.
Solve the async when reading UF and UIP
Changes in v2:
Add UIP check logic.
Add logic that next second tick will occur in exactly 500ms later after reset
divider
C
Change DM(date mode) and 24/12 control bit don't affect the internal
registers. It only indicates what format is using for those registers. So
we don't need to update time format when it is modified.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 10 +-
1 files changed, 1 insertions(
There has no need to use two periodic timer to update RTC time.
In this patch, we only update it when guest reading it.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 207 +-
1 files changed, 66 insertions(+), 141 deletions(-)
diff --git a/
The UIP(update in progress) is set when RTC is updating. And the update
cycle begins 244us later after UIP is set. And it is cleared when update end.
.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/hw/mc
Use a timer to emulate update cycle. When update cycle ended and UIE is
setting,
then raise an interrupt. The timer runs only when UF or AF is cleared.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 86 ++
1 files changed, 80 insertions(
The first update cycle begins one - half seconds later when divider
reset is removing.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 38 +-
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 6ebb8f6..
Add the alarm check when update cycle ended. If alarm is fired,
also AIE bit is setting, then raise a interrupt
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 48 ++--
1 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/hw/mc146818rtc.c
The new logic is compatible with old. So it should not block to migrate
from old version. But new version cannot migrate to old.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 48
1 files changed, 44 insertions(+), 4 deletions(-)
diff --git a
After restoring i8254, the f->buf_index points to a wrong place. It should be
caused by loading i8254.
best regards
yang
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Jan Kiszka
> Sent: Friday, March 02, 2012 4:48 PM
> To: Ren,
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, March 02, 2012 8:14 PM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; Jan Kiszka; kvm@vger.kernel.org;
> aligu...@us.ibm.com; Marcelo Tosatti
>
> -Original Message-
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Friday, March 09, 2012 9:36 AM
> > ---
> > hw/mc146818rtc.c | 10 +-
> > 1 files changed, 1 insertions(+), 9 deletions(-)
> >
> > diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
> > index a46fdfc..
I think the better fixing is to update the cmos before reading the RTC. And in
my patch, it will do it.
best regards
yang
> -Original Message-
> From: Zhang, Yang Z
> Sent: Friday, March 09, 2012 9:54 AM
> To: Marcelo Tosatti
> Cc: qemu-de...@nongnu.org; Jan Kiszka; kvm@
Is there any comments with the version 3?
best regards
yang
> -Original Message-
> From: Zhang, Yang Z
> Sent: Friday, March 02, 2012 2:59 PM
> To: qemu-de...@nongnu.org
> Cc: Jan Kiszka; kvm@vger.kernel.org; kvm@vger.kernel.org; aligu...@us.ibm.com;
> Paolo Bonzin
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, March 14, 2012 4:35 PM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; Jan Kiszka; kvm@vger.kernel.org;
> aligu...@us.ibm.com; Marcelo Tosatti
> Subject: Re: [PATCH v3 0/7] RTC:
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, March 14, 2012 4:54 PM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; Jan Kiszka; kvm@vger.kernel.org;
> aligu...@us.ibm.com; Marcelo Tosatti
> Subject: Re: [PATCH v3 0/7] RTC:
Changes in v4:
Rebase to latest head.
Changing in patch 6:
Set the timer to one second earlier before target alarm when AF bit is
clear. In version 3, in order to solve the async between UF, AF and UIP, the
timer will keep running when UF or AF are clear. This is a little ugly,
especial
Change DM(date mode) and 24/12 control bit don't affect the internal registers.
It only indicates what format is using for those registers. So we don't need to
update time format when it is modified.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 10 +-
1 files changed, 1 insertion
There has no need to use two periodic timer to update RTC time. In this patch,
we only update it when guest reading it.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 207 +-
1 files changed, 66 insertions(+), 141 deletions(-)
diff --git a
The UIP(update in progress) is set when RTC is updating. And the update cycle
begins 244us later after UIP is set. And it is cleared when update end.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/hw/mc14
The first update cycle begins one - half seconds later when divider reset is
removing.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 38 +-
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 6ebb8f6.
Use a timer to emulate update cycle. When update cycle ended and UIE is
setting, then raise an interrupt. The timer runs only when UF or AF is cleared.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 86 ++
1 files changed, 80 insertions(+)
Changing in this patch:
Set the timer to one second earlier before target alarm when AF bit is
clear. In version 3, in order to solve the async between UF, AF and UIP, the
timer will keep running when UF or AF are clear. This is a little ugly,
especially when a userspace program is usin
The new logic is compatible with old. So it should not block migrate from old
version. But new version cannot migrate to old.
Signed-off-by: Yang Zhang
---
hw/mc146818rtc.c | 48
1 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/h
> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: Tuesday, March 20, 2012 10:05 PM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; Paolo Bonzini; aligu...@us.ibm.com;
> kvm@vger.kernel.org
> Subject: Re: [Qemu-deve
> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: Wednesday, March 21, 2012 1:39 AM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; Paolo Bonzini; aligu...@us.ibm.com;
> kvm@vger.kernel.org
> Subject: Re: [Qemu-devel] [P
> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: Tuesday, March 20, 2012 10:16 PM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; Paolo Bonzini; aligu...@us.ibm.com;
> kvm@vger.kernel.org
> Subject: Re: [Qemu-deve
> -Original Message-
> From: Stefano Stabellini [mailto:stefano.stabell...@eu.citrix.com]
> Sent: Wednesday, March 21, 2012 2:04 AM
>
> On Mon, 19 Mar 2012, Zhang, Yang Z wrote:
> > Use a timer to emulate update cycle. When update cycle ended and UIE is
> setting,
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> I attach a patch that fixes some problems with divider reset and in
> general simplifies the logic. Even with the patch, however, I still see
> failures in my test case unfortunately. Probably there are rounding
> e
-Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
>
> Il 22/03/2012 01:23, Zhang, Yang Z ha scritto:
> > Actually, I also see some failures during testing. And most of them
> > are fail to pass the 244us update cycle checking. Since we are in
>
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, March 22, 2012 11:05 AM
> To: Zhang, Yang Z
> Cc: qemu-de...@nongnu.org; aligu...@us.ibm.com; kvm@vger.kernel.org
> Subject: Re: [PATCH v4 0/7] RTC: New logic to emulate RTC
>
Since this series is pending in mail list for long time. And it's really a big
feature for Nested. Also, I doubt the original authors(Jun and Nahav)should not
have enough time to continue it. So I will pick it up. :)
See comments below:
Paolo Bonzini wrote on 2013-05-20:
> Il 19/05/2013 06:52,
>Il 03/07/2013 10:24, Arthur Chunqi Li ha scritto:
>> Hi Gleb and Paolo,
>> When I write test cases for nested virt and found that reading/writing
>> IA32_FEATURE_CONTROL will be simply ignored or return 0 (in
>> arch/x86/kvm/vmx.c) in VM. Checking this MSR will be done by some
>> hypervisors (
> On Tue, Jul 02, 2013 at 03:01:24AM +, Zhang, Yang Z wrote:
>>>>>> Since this series is pending in mail list for long time. And
>>>>>> it's really a big feature for Nested. Also, I doubt the
>>>>>> original authors(Jun and Naha
> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Monday, July 08, 2013 8:38 PM
> To: Zhang, Yang Z
> Cc: Jan Kiszka; Paolo Bonzini; Nakajima, Jun; kvm@vger.kernel.org
> Subject: Re: [PATCH v3 01/13] nEPT: Support LOAD_IA32_EFER entry/exit
> co
Gleb Natapov wrote on 2013-08-01:
> From: Nadav Har'El
>
> Recent KVM, since
> http://kerneltrap.org/mailarchive/linux-kvm/2010/5/2/6261577
> switch the EFER MSR when EPT is used and the host and guest have different
> NX bits. So if we add support for nested EPT (L1 guest using EPT to run L2)
>
Jan Kiszka wrote on 2013-08-02:
> On 2013-08-02 05:04, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2013-08-01:
>>> From: Nadav Har'El
>>>
>>> Recent KVM, since
>>> http://kerneltrap.org/mailarchive/linux-kvm/2010/5/2/6261577
>>> switc
Gleb Natapov wrote on 2013-08-06:
> On Tue, Aug 06, 2013 at 10:39:59AM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> If nested EPT is enabled, the L2 guest may change CR3 without any exits.
>> We therefore have to read the current value from the VMCS when
>> switching to L1. However, if pagi
Gleb Natapov wrote on 2013-08-06:
> On Tue, Aug 06, 2013 at 11:44:41AM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2013-08-06:
>>> On Tue, Aug 06, 2013 at 10:39:59AM +0200, Jan Kiszka wrote:
>>>> From: Jan Kiszka
>>>>
>>>> If nest
Gleb Natapov wrote on 2013-08-06:
> On Tue, Aug 06, 2013 at 02:12:51PM +0000, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2013-08-06:
>>> On Tue, Aug 06, 2013 at 11:44:41AM +, Zhang, Yang Z wrote:
>>>> Gleb Natapov wrote on 2013-08-06:
>>>>>
Wanpeng Li wrote on 2014-07-17:
> WARNING: CPU: 9 PID: 7251 at arch/x86/kvm/vmx.c:8719
> nested_vmx_vmexit+0xa4/0x233 [kvm_intel]() Modules linked in: tun
> nfsv3 nfs_acl auth_rpcgss oid_registry nfsv4 dns_resolver nfs fscache
> lockd sunrpc pci_stub netconsole kvm_intel kvm bridge stp llc autofs4
ress and the L2 can boot up, however, slowly. The original idea of
>> this fix vid injection patch is from "Zhang, Yang Z"
>> .
>>
>> Interrupt which delivered by vid should be injected to L1 by L0 if
>> current is in L1, or should be injected
Paolo Bonzini wrote on 2014-07-17:
> Il 17/07/2014 06:56, Wanpeng Li ha scritto:
>> && nested_exit_intr_ack_set(vcpu)) {
>> int irq = kvm_cpu_get_interrupt(vcpu);
>> +
>> +if (irq < 0 && kvm_apic_vid_enabled(vcpu->kvm))
>> +irq = kvm_get_apic_in
Hi all,
I see the deadline of CFP for KVM forum is July 27, 2014. But I found there is
no kvm forum selection list when I tried to submit a presentation yesterday. Is
the CFP closed early than expected?
BTW, it is in July 27 in US when sending this mail.
best regards
yang
--
To unsubscribe fr
Paolo Bonzini wrote on 2014-07-31:
> Il 31/07/2014 10:03, Wanpeng Li ha scritto:
>>> One thing:
>>>
+ if (nested_cpu_has(vmcs12, CPU_BASED_TPR_SHADOW))
+ vmcs_write32(TPR_THRESHOLD, vmcs12->tpr_threshold);
>>>
>>> I think you can just do this write unconditionally, since most
Paolo Bonzini wrote on 2014-08-01:
> Il 01/08/2014 02:57, Zhang, Yang Z ha scritto:
>>> TPR_THRESHOLD will be likely written as zero, but the processor
>>> will never use it anyway. It's just a small optimization because
>>> nested_cpu_has(vmcs12, CPU_BASED_
Wanpeng Li wrote on 2014-08-04:
> This patch fix bug https://bugzilla.kernel.org/show_bug.cgi?id=61411
>
> TPR shadow/threshold feature is important to speed up the Windows guest.
> Besides, it is a must feature for certain VMM.
>
> We map virtual APIC page address and TPR threshold from L1 VMCS.
Paolo Bonzini wrote on 2014-08-05:
> Il 05/08/2014 09:56, Zhang, Yang Z ha scritto:
>> Wanpeng Li wrote on 2014-08-04:
>>> This patch fix bug
>>> https://bugzilla.kernel.org/show_bug.cgi?id=61411
>>>
>>> TPR shadow/threshold feature is important to spe
Paolo Bonzini wrote on 2014-07-31:
> Currently, the EOI exit bitmap (used for APICv) does not include
> interrupts that are masked. However, this can cause a bug that manifests
> as an interrupt storm inside the guest. Alex Williamson reported the
> bug and is the one who really debugged this; I
Paolo Bonzini wrote on 2014-08-06:
> Il 06/08/2014 16:03, Zhang, Yang Z ha scritto:
>> Paolo Bonzini wrote on 2014-07-31:
>>> Probably, the guest is masking the interrupt in the redirection
>>> table in the interrupt routine, i.e. while the interrupt is set in a
>&g
Paolo Bonzini wrote on 2014-08-07:
> Il 07/08/2014 03:31, Zhang, Yang Z ha scritto:
>> Let me give an example to see whether my concern is a real problem:
>> Guest allocates a vector and set it in IOAPIC entry to deliver
>> interrupt. Later it masks the IOAPIC entry(means stop
Chen, Tiejun wrote on 2014-08-15:
> On 2014/8/14 3:16, Wei Wang wrote:
>> From: Yang Zhang
>>
>> Guest may mask the IOAPIC entry before issue EOI. In such case,
>> EOI will not be intercepted by hypervisor due to the corrensponding
>
> s/corrensponding/corresponding
>
>> bit in eoi exit bitmap
Paolo Bonzini wrote on 2014-08-27:
> Il 27/08/2014 16:05, Wei Wang ha scritto:
> > Guest may mask the IOAPIC entry before issue EOI. In such case, EOI
> > will not be intercepted by the hypervisor, since the corresponding bit
> > in eoi_exit_bitmap is not set after the masking of IOAPIC entry.
> >
Paolo Bonzini wrote on 2015-10-01:
Hi Paolo
Sorry for the late reply. I am just back from vacation.
>
>
> On 13/04/2015 13:34, Nadav Amit wrote:
>> x86 architecture defines differences between the reset and INIT
>> sequences. INIT does not initialize the FPU (including MMX, XMM, YMM,
>> etc.),
Paolo Bonzini wrote on 2015-11-13:
> Commit 7a1638ce4220 ("nEPT: Redefine EPT-specific link_shadow_page()",
> 2013-08-05) says:
>
> Since nEPT doesn't support A/D bit, we should not set those bit
> when building the shadow page table.
> but this is not necessary. Even though nEPT doesn't
Michael S. Tsirkin wrote on 2015-11-16:
> This patch adds a new parameter: eptp_switching_test, which enables
> testing EPT switching on VMX if supported by hardware. All EPT
> entries are initialized to the same value so this adds no useful
> functionality by itself, but can be used to test VMFUN
H. Peter Anvin wrote on 2015-04-24:
> On 04/23/2015 08:28 AM, Dave Hansen wrote:
>> On 04/23/2015 02:13 PM, Liang Li wrote:
>>> When compiling kernel on westmere, the performance of eager FPU is
>>> about 0.4% faster than lazy FPU.
>>
>> Do you have an theory why this is? What does the regression
Paolo Bonzini wrote on 2015-04-24:
>
>
> On 24/04/2015 03:16, Zhang, Yang Z wrote:
>>> This is interesting since previous measurements on KVM have had the
>>> exact opposite results. I think we need to understand this a lot
>>> more.
>>
>> W
Paolo Bonzini wrote on 2015-04-24:
>
>
> On 24/04/2015 09:46, Zhang, Yang Z wrote:
>>> On the other hand vmexit is lighter and lighter on newer
>>> processors; a Sandy Bridge has less than half the vmexit cost of a
>>> Core 2 (IIRC
>>> 1000 vs.
201 - 300 of 357 matches
Mail list logo
