From: Sean Christopherson <seanjc@google.com>
To: alexjlzheng@gmail.com
Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Jinliang Zheng <alexjlzheng@tencent.com>
Subject: Re: [PATCH 2/2] KVM: x86: Adjust return value of pic_poll_read()
Date: Tue, 18 Apr 2023 08:19:00 -0700 [thread overview]
Message-ID: <ZD605NFbjiCBX9jW@google.com> (raw)
In-Reply-To: <20230418104743.842683-3-alexjlzheng@tencent.com>
On Tue, Apr 18, 2023, alexjlzheng@gmail.com wrote:
> From: Jinliang Zheng <alexjlzheng@tencent.com>
>
> Returning 0x07 raises ambiguity when no interrupt is in pic_poll_read().
> Although it will not cause a functional exception (Bit 7 is 0 means no
From KVM's perspective, it's a functional change. It _shouldn't_ impact the
overall functionality of the guest, but we have no idea what guest code exists
in the wild.
> interrupt), it will easily make developers mistakenly think that a
> spurious interrupt (IRQ 7) has been returned.
>
> Return 0x00 instread of 0x07.
Again, I do not want to introduce a functional change in this code without evidence
that the change fixes something for a real world guest. Based on your response[*],
that is not the case.
A comment explaining the KVM behavior would be very welcome, but I'm not taking
this patch.
[*] https://lore.kernel.org/all/20230418075923.752113-1-alexjlzheng@tencent.com
prev parent reply other threads:[~2023-04-18 15:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230418104743.842683-1-alexjlzheng@tencent.com>
2023-04-18 10:47 ` [PATCH 1/2] KVM: x86: Fix poll command alexjlzheng
2023-04-18 10:47 ` [PATCH 2/2] KVM: x86: Adjust return value of pic_poll_read() alexjlzheng
2023-04-18 15:19 ` Sean Christopherson [this message]
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=ZD605NFbjiCBX9jW@google.com \
--to=seanjc@google.com \
--cc=alexjlzheng@gmail.com \
--cc=alexjlzheng@tencent.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.