From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: kvm-devel <kvm@vger.kernel.org>,
"Yang, Sheng" <sheng.yang@intel.com>,
Jan Kiszka <jan.kiszka@siemens.com>
Subject: Re: [PATCH] KVM: x86: Don't deliver PIC interrupts to disabled APICs - v2
Date: Wed, 22 Oct 2008 22:44:48 +0200 [thread overview]
Message-ID: <48FF90C0.3030001@web.de> (raw)
In-Reply-To: <48FF493F.6050303@siemens.com>
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Avi Kivity wrote:
>>>> Jan Kiszka wrote:
>>>>> [ taking Sheng's comments into account ]
>>>>>
>>>>> The logic of kvm_apic_accept_pic_intr has a minor, practically hardly
>>>>> relevant incorrectness: PIC interrupts are still delivered even if the
>>>>> APIC of VPU0 (BSP) is disabled. This does not comply with the Virtual
>>>>> Wire mode according to the Intel MP spec.
>>>>>
>>>> This breaks Windows XP with the Standard PC HAL, so I am unapplying this
>>>> patch.
>>> Hmm, this points to either an APIC setup or BIOS bug. To my
>>> understanding, the Standard PC HAL should not fiddle with the APIC, so
>>> what the BIOS leaves behind should counts. But I think I found no traces
>>> of APIC manipulation in rombios32.c.
>> Manipulation on UP systems. There is fiddling for SMP. But I will check
>> again.
>
> I take everything back: For yet unknown reasons Windows' standard HAL
> actually decides to disable the APIC actively. Either there is a
> short-path around a disabled APIC for Virtual Wire mode in Real Live
> (though I fail to read this out of the spec), or Windows simply has a
> bug here (MS insists on NOT supporting the Standard HAL on APIC systems
> [1] - precisely the setup KVM is providing). Sheng, any comments on
> this? Guess we have to live with the previous version, maybe with some
> refactoring + commenting.
I was curious and played with my corresponding qemu patch [1]: It works
with the same Windows image that hangs under KVM. Then I looked at a
prominent guest-visible difference: the reported CPU type. QEMU claims
to provide a CPU called "qemu64" by default. Changing this to Pentium2
or newer makes Windows issue the lethal APIC disable command. On the
other hand, calling kvm with "-cpu pentium" makes Windows boot again.
However, I still can't tell from this if we see a Windows bug or if the
change is incorrect (but me feeling tends to the former).
Jan
[1] http://permalink.gmane.org/gmane.comp.emulators.qemu/31429
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2008-10-22 20:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-20 8:50 [PATCH] KVM: x86: Don't deliver PIC interrupts to disabled APICs Jan Kiszka
2008-10-20 11:51 ` Sheng Yang
2008-10-20 11:56 ` Jan Kiszka
2008-10-20 12:02 ` Jan Kiszka
2008-10-20 12:06 ` [PATCH] KVM: x86: Don't deliver PIC interrupts to disabled APICs - v2 Jan Kiszka
2008-10-20 12:22 ` Sheng Yang
2008-10-22 10:22 ` Avi Kivity
2008-10-22 14:08 ` Avi Kivity
2008-10-22 15:09 ` Jan Kiszka
2008-10-22 15:12 ` Jan Kiszka
2008-10-22 15:39 ` Jan Kiszka
2008-10-22 20:44 ` Jan Kiszka [this message]
2008-10-23 1:51 ` Yang, Sheng
2008-10-23 8:11 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48FF90C0.3030001@web.de \
--to=jan.kiszka@web.de \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=sheng.yang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.