Chris Lalancette <[EMAIL PROTECTED]> writes:
> this allows my RHEL-4 guest to successfully boot, although obviously the NMI
> watchdog which it thinks it set up is not actually working.
That's fine. On a virtualized environment you don't really need a NMI watchdog
because you can always debug from
Joerg Roedel wrote:
>> OK, yeah, I read some of those threads over the weekend. It is a larger
>> problem than just this crash, and probably one to be solved later.
>> I have attached a patch which just discards all writes, as you
>> suggested;
>> this allows my RHEL-4 guest to successf
On Mon, Apr 28, 2008 at 10:17:37AM -0400, Chris Lalancette wrote:
> Joerg Roedel wrote:
> > We already discussed the emulation of the performance counter registers
> > in the past. The conclusion is, that we loose live migration with that
> > emulation because performance monitoring is implemented
Joerg Roedel wrote:
> We already discussed the emulation of the performance counter registers
> in the past. The conclusion is, that we loose live migration with that
> emulation because performance monitoring is implemented differently
> between AMD and Intel systems. Maybe discarding _any_ writes
On Fri, Apr 25, 2008 at 02:43:19PM -0400, Chris Lalancette wrote:
> Unfortunately, we can't just "fake emulate" MSR_K7_PERFCTR[0-3] like we are
> doing for MSR_K7_EVNTSEL[0-3]; if they are there, linux expects to be able to
> put values into them. I think the correct solution here is to emulate
>
Avi Kivity wrote:
>
> Hmm, looking back at the dump:
>
>> 1811:8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax
>> 1817:83 f8 03cmp$0x3,%eax
>> 181a:0f 87 e2 01 00 00 ja 1a02
>
> So while gcc is using %rsi, it loads the result back into
Avi Kivity wrote:
>
> Hmm, looking back at the dump:
>
>> 1811:8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax
>> 1817:83 f8 03cmp$0x3,%eax
>> 181a:0f 87 e2 01 00 00 ja 1a02
>
> So while gcc is using %rsi, it loads the result back into
Chris Lalancette wrote:
> Avi Kivity wrote:
>
>> Now it uses %rsi instead of %esi, and any junk in the upper bits will
>> cause the ja to be taken.
>>
>> We need to get a reduced testcase to the gcc folks, this is a serious
>> bug. Any changes in the code to work around this would be fragile.
Avi Kivity wrote:
> Now it uses %rsi instead of %esi, and any junk in the upper bits will
> cause the ja to be taken.
>
> We need to get a reduced testcase to the gcc folks, this is a serious
> bug. Any changes in the code to work around this would be fragile.
>
Avi,
I've now filed a bug
Avi Kivity wrote:
>
>> 1811:8d 86 00 00 ff 3f lea0x3fff(%rsi),%eax
>> 1817:83 f8 03cmp$0x3,%eax
>> 181a:0f 87 e2 01 00 00 ja 1a02
> Now it uses %rsi instead of %esi, and any junk in the upper bits will
> cause the ja to be taken
Chris Lalancette wrote:
> Avi Kivity wrote:
>
>> You mean the gcc generates wrong code? It seems fine here (though
>> wonderfully obfuscated).
>>
>> Can you attach an objdump -Sr svm.o? Also, what gcc version are you using?
>>
>>
>
> (sending attachment in private mail, so I don't spam t
Chris Lalancette wrote:
> Avi, Joerg,
> While trying to boot a RHEL-4 guest on latest KVM tip on an AMD machine,
> I
> found that the guest would consistently crash when trying to setup the NMI
> watchdog. I traced it down to the following commit:
>
> 51ef1ac7b23ee32bfcc61c229d634fdc1c68b38a
12 matches
Mail list logo