Tested with the _correct_ Kernel[1] (that has Radim's patch) now --
applied it on both L0 and L1.
Result: Same as before -- Booting L2 causes L1 to reboot. However, the
stack trace from `dmesg` on L0 is took slightly different path than
before -- it's using MSR handling:
. . .
[Fe
On Mon, Feb 23, 2015 at 05:14:37PM +0100, Kashyap Chamarthy wrote:
> On Mon, Feb 23, 2015 at 02:56:11PM +0100, Radim Krčmář wrote:
> > 2015-02-22 16:46+0100, Kashyap Chamarthy:
> > > Radim,
> > >
> > > I just tested with your patch[1] in this thread. I built a Fedora
> > > Kernel[2] with it, and i
On Mon, Feb 23, 2015 at 02:56:11PM +0100, Radim Krčmář wrote:
> 2015-02-22 16:46+0100, Kashyap Chamarthy:
> > Radim,
> >
> > I just tested with your patch[1] in this thread. I built a Fedora
> > Kernel[2] with it, and installed (and booted into) it on both L0 and L1.
> >
> > Result: I don't have
2015-02-22 16:46+0100, Kashyap Chamarthy:
> Radim,
>
> I just tested with your patch[1] in this thread. I built a Fedora
> Kernel[2] with it, and installed (and booted into) it on both L0 and L1.
>
> Result: I don't have good news, I'm afraid: L1 *still* reboots when an
> L2 guest is boo
Radim,
I just tested with your patch[1] in this thread. I built a Fedora
Kernel[2] with it, and installed (and booted into) it on both L0 and L1.
Result: I don't have good news, I'm afraid: L1 *still* reboots when an
L2 guest is booted. And, L0 throws the stack trace that was
pre
On Fri, Feb 20, 2015 at 05:14:15PM +0100, Radim Krčmář wrote:
> 2015-02-19 23:28+0100, Kashyap Chamarthy:
> > On Thu, Feb 19, 2015 at 10:10:11PM +0100, Kashyap Chamarthy wrote:
> > > On Thu, Feb 19, 2015 at 05:02:22PM +0100, Radim Krčmář wrote:
[. . .]
> > Then, I did another test:
> >
> > - R
2015-02-19 23:28+0100, Kashyap Chamarthy:
> On Thu, Feb 19, 2015 at 10:10:11PM +0100, Kashyap Chamarthy wrote:
> > On Thu, Feb 19, 2015 at 05:02:22PM +0100, Radim Krčmář wrote:
>
> [. . .]
>
> > > Can you try if the following patch works?
> >
> > Sure, will test a Kernel built with the below pat
On Thu, Feb 19, 2015 at 10:10:11PM +0100, Kashyap Chamarthy wrote:
> On Thu, Feb 19, 2015 at 05:02:22PM +0100, Radim Krčmář wrote:
[. . .]
> > Can you try if the following patch works?
>
> Sure, will test a Kernel built with the below patch and report back.
Hmm, I'm stuck with a meta issue.
I
On Thu, Feb 19, 2015 at 05:02:22PM +0100, Radim Krčmář wrote:
> 2015-02-19 16:01+0100, Radim Krčmář:
> > 2015-02-19 13:07+0100, Kashyap Chamarthy:
> > 5f3d5799974b8 KVM: nVMX: Rework event injection and recovery:
> > This concept is based on the rule that a pending vmlaunch/vmresume is
> > not
2015-02-19 17:02+0100, Radim Krčmář:
> Fixes: e011c663b9c7 ("Check all exceptions for intercept during delivery to
> L2")
Note: I haven't verified that it was introduced by this patch, just
nothing against the hypothesis popped out in a short gravedigging.
--
To unsubscribe from this list: send t
2015-02-19 16:01+0100, Radim Krčmář:
> 2015-02-19 13:07+0100, Kashyap Chamarthy:
> 5f3d5799974b8 KVM: nVMX: Rework event injection and recovery:
> This concept is based on the rule that a pending vmlaunch/vmresume is
> not canceled. Otherwise, we would risk to lose injected events or leak
> t
2015-02-19 13:07+0100, Kashyap Chamarthy:
> Just did two tests with 3.18:
>
> (1) Kernel 3.18 on L0 and 3.20 on L1
>
> Result: Booting L2 guest causes L1 to reboot, and the same[*] stack
> trace on L0 (mentioned on this thread previously).
>
> But, annoyingly enough,
On Wed, Feb 18, 2015 at 05:42:37PM +0100, Paolo Bonzini wrote:
>
>
> On 17/02/2015 12:24, Kashyap Chamarthy wrote:
> > Afraid, I didn't bisect it, but I just wanted to note that the above
> > specific WARN was introduced in the above commit.
> >
> > I'm sure this Kernel (on L0) does not exhibit
On 17/02/2015 12:24, Kashyap Chamarthy wrote:
> Afraid, I didn't bisect it, but I just wanted to note that the above
> specific WARN was introduced in the above commit.
>
> I'm sure this Kernel (on L0) does not exhibit the problem:
> kernel-3.17.4-301.fc21.x86_64. But, if I had either of these t
On Tue, Feb 17, 2015 at 07:07:21PM +0100, Jan Kiszka wrote:
> On 2015-02-17 19:00, Bandan Das wrote:
> > Kashyap Chamarthy writes:
> > ..
> >>>
> >>> Does enable_apicv make a difference?
> >>
> >> Actually, I did perform a test (on Paolo's suggestion on IRC) with
> >> enable_apicv=0 on physical ho
On 2015-02-17 19:00, Bandan Das wrote:
> Kashyap Chamarthy writes:
> ..
>>>
>>> Does enable_apicv make a difference?
>>
>> Actually, I did perform a test (on Paolo's suggestion on IRC) with
>> enable_apicv=0 on physical host, and it didn't make any difference:
>>
>> $ cat /proc/cmdline
>> BOOT_IM
Kashyap Chamarthy writes:
..
>>
>> Does enable_apicv make a difference?
>
> Actually, I did perform a test (on Paolo's suggestion on IRC) with
> enable_apicv=0 on physical host, and it didn't make any difference:
>
> $ cat /proc/cmdline
> BOOT_IMAGE=/vmlinuz-3.20.0-0.rc0.git5.1.fc23.x86_64
> ro
On Tue, Feb 17, 2015 at 07:02:14AM +0100, Jan Kiszka wrote:
> On 2015-02-16 21:40, Kashyap Chamarthy wrote:
> > I can observe this only one of the Intel Xeon machines (which has 48
> > CPUs and 1TB memory), but very reliably reproducible.
> >
> >
> > Reproducer:
> >
> > - Just ensure physical
On 2015-02-16 21:40, Kashyap Chamarthy wrote:
> I can observe this only one of the Intel Xeon machines (which has 48
> CPUs and 1TB memory), but very reliably reproducible.
>
>
> Reproducer:
>
> - Just ensure physical host (L0) and guest hypervisor (L1) are running
> 3.20.0-0.rc0.git5.1 Ke
I can observe this only one of the Intel Xeon machines (which has 48
CPUs and 1TB memory), but very reliably reproducible.
Reproducer:
- Just ensure physical host (L0) and guest hypervisor (L1) are running
3.20.0-0.rc0.git5.1 Kernel (I used from Fedora's Rawhide).
Preferably on an Inte
20 matches
Mail list logo
