On 2014-09-23 10:22, Paolo Bonzini wrote:
> kvm_get_xtime_nsec could overflow. If we make kvm_get_boot_base_ns
> compute the equivalent of 3.17's base_mono+offs_boot formula (instead of
> just offs_boot), we can avoid that and drop kvm_get_xtime_nsec altogether.
Applied, thanks.
Any suggestions
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
commit 3dc4f7cfb7441e5e0fed3a02fc81cdaabd28300a
Author: Marcelo Tosatti
AuthorDate: Tue Nov 27 23:28:56 2012 -0200
Commit: Marcelo Tosatti
CommitDate: Tue Nov 27 23:29:10 2012 -0200
x86: kvm guest:
Il 30/09/2014 09:54, Jan Kiszka ha scritto:
>> > kvm_get_xtime_nsec could overflow. If we make kvm_get_boot_base_ns
>> > compute the equivalent of 3.17's base_mono+offs_boot formula (instead of
>> > just offs_boot), we can avoid that and drop kvm_get_xtime_nsec altogether.
> Applied, thanks.
>
>
On 2014-09-30 10:43, Paolo Bonzini wrote:
> Il 30/09/2014 09:54, Jan Kiszka ha scritto:
kvm_get_xtime_nsec could overflow. If we make kvm_get_boot_base_ns
compute the equivalent of 3.17's base_mono+offs_boot formula (instead of
just offs_boot), we can avoid that and drop kvm_get_xti
Hi Anup,
thanks for the re-spin and sorry for the delay.
Looks better now, some minor comments below.
On 19/09/14 00:57, Anup Patel wrote:
> Instead, of trying out each and every target type we should
> use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target type
> for KVM ARM/ARM64.
>
> If K
Hi Anup,
this looks good now, only one minor formatting thing below.
On 19/09/14 00:57, Anup Patel wrote:
> If in-kernel KVM support PSCI-0.2 emulation then we should set
> KVM_ARM_VCPU_PSCI_0_2 feature for each guest VCPU and also
> provide "arm,psci-0.2","arm,psci" as PSCI compatible string.
>
On 19/09/14 00:57, Anup Patel wrote:
> The KVM_EXIT_SYSTEM_EVENT exit reason was added to define
> architecture independent system-wide events for a Guest.
>
> Currently, it is used by in-kernel PSCI-0.2 emulation of
> KVM ARM/ARM64 to inform user space about PSCI SYSTEM_OFF
> or PSCI SYSTEM_RESET
Hi all,
This is just to let you know that the VM System Spec is available in its
'final' v1.0 format here:
http://www.linaro.org/docs/
-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 2014/9/30 15:59, Fengguang Wu wrote:
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
commit 3dc4f7cfb7441e5e0fed3a02fc81cdaabd28300a
Author: Marcelo Tosatti
AuthorDate: Tue Nov 27 23:28:56 2012 -0200
Commit: Marcelo Tosatti
CommitDate: Tue Nov 2
Il 30/09/2014 10:48, Jan Kiszka ha scritto:
>> > +w('{')
>> > +w('\treturn __kvm_mmu_notifier_clear_flush_young(mn, mm, hva,
>> > hva+1);')
> Ah, end=start+1, it's that easy!
>
Yes, that's how kvm_handle_hva is implemented on top of
kvm_handle_hva_range. So, now that kvm
On Tue, Sep 30, 2014 at 09:48:02AM +0800, Shannon Zhao wrote:
> Hi Christoffer,
>
> On 2014/9/26 21:44, Christoffer Dall wrote:
> > On Fri, Sep 26, 2014 at 12:16:35PM +0200, Christoffer Dall wrote:
> >> On Fri, Sep 26, 2014 at 05:26:00PM +0800, Shannon Zhao wrote:
> >>>
> >>>
> >>> On 2014/9/26 16
Il 30/09/2014 12:25, Chen, Tiejun ha scritto:
>>
>> [0.00] Pid: 0, comm: swapper Not tainted
>> 3.7.0-rc3-00112-g3dc4f7c #1
>
> Looks you're working with old kernel, so its worth trying the latest again.
That's just the commit where the bisection ended, and the first one that
introduced t
Il 30/09/2014 09:59, Fengguang Wu ha scritto:
> +--++++
> | | 71056ae22d |
> 3dc4f7cfb7 | d778df51c0 |
> +---
Hi Christoffer,
On Thu, Sep 25, 2014 at 08:42:53PM +0100, Christoffer Dall wrote:
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 7796051..048f37f 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -409,7 +409,7 @@ static void update_vttbr(struct kvm *kvm)
> k
On Tue, Sep 30, 2014 at 02:05:09PM +0200, Paolo Bonzini wrote:
> Il 30/09/2014 09:59, Fengguang Wu ha scritto:
> > +--++++
> > | | 71056ae22d
On Thu, Sep 25, 2014 at 08:42:54PM +0100, Christoffer Dall wrote:
> When creating or moving a memslot, make sure the IPA space is within the
> addressable range of the guest. Otherwise, user space can create too
> large a memslot and KVM would try to access potentially unallocated page
> table ent
Even after the recent fix, the assertion on paging_tmpl.h is triggered.
Apparently, the assertion wants to check that the PAE is always set on
long-mode, but does it in incorrect way. Note that the assertion is not
enabled unless the code is debugged by defining MMU_DEBUG.
Signed-off-by: Nadav Am
This patch-set includes miscellaneous bug fixes.
Patches 1-2 fix KVM bugs that affect the correct behavior of VMs.
Patches 3-5 have no apparent implications in normal use. Nonetheless, they fix
code which is bluntly wrong.
Patch 6 is version 2 of previously submitted patch. It was revised accord
Determining flat mode according to cid_mask is wrong, since currently KVM
supports zero clusters in x2apic mode. Use ldr_bits instead.
Since we recalculate the apic map whenever the DFR is changed, the bug appears
to have no effect, and perhaps the entire check can be removed.
Signed-off-by: Nada
In long-mode, when the address size is 4 bytes, the linear address is not
truncated as the emulator mistakenly does. Instead, the offset within the
segment (the ea field) should be truncated according to the address size.
As Intel SDM says: "In 64-bit mode, the effective address components are ad
GP and SS exceptions deliver as error-code the segment selector if the
exception occurred when the segment is loaded. However, if the exception
occurs during the memory access itself, due to limit violations, the error-code
should be zero. Fix it.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/emu
NoBigReal emulation should consider the effective address is between 0 and
0x instead of checking the logical address. Currently there are no
instructions which are marked with NoBigReal flag, so this bug currently has no
impact.
Signed-off-by: Nadav Amit
---
arch/x86/kvm/emulate.c | 4 ++--
Intel SDM 17.2.4 (Debug Control Register (DR7)) says: "The processor clears the
GD flag upon entering to the debug exception handler." This sentence may be
misunderstood as if it happens only on #DB due to debug-register protection,
but it happens regardless to the cause of the #DB.
Fix the behavi
Ping?
On Mon, Sep 22, 2014 at 02:19:14PM -0300, Marcelo Tosatti wrote:
> On Tue, Sep 09, 2014 at 12:28:11PM -0300, Marcelo Tosatti wrote:
> > On Mon, Jul 21, 2014 at 04:14:24PM +0300, Gleb Natapov wrote:
> > > On Wed, Jul 09, 2014 at 04:12:53PM -0300, mtosa...@redhat.com wrote:
> > > > Reload remo
On Tue, Sep 30, 2014 at 02:05:09PM +0200, Paolo Bonzini wrote:
> Il 30/09/2014 09:59, Fengguang Wu ha scritto:
> > +--++++
> > | | 71056ae22d
2014-09-29 21:15+0300, Nadav Amit:
> KVM does not deliver x2APIC broadcast messages with physical mode. Intel SDM
> (10.12.9 ICR Operation in x2APIC Mode) states: "A destination ID value of
> _H is used for broadcast of interrupts in both logical destination and
> physical destination mode
Hi Paolo and Gleb,
The attached file is a preliminary version of AMD vPMU support for KVM.
Currently I am working on a formal patch set; but realized that there
are some design choice to make (see below). I thought it is better to
send it out now, asking for your comments before sending out pa
27 matches
Mail list logo