public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 kvm RESEND] KVM: i8259: Fix poll command
Date: Mon, 10 Apr 2023 09:32:15 -0700	[thread overview]
Message-ID: <ZDQ6D6BX/3mqhCbW@google.com> (raw)
In-Reply-To: <20230410031021.4145297-1-alexjlzheng@tencent.com>

Please don't use RESEND as a ping, just respond to the original patch with a "Ping",
or any question you might have.  I know Documentation/process/submitting-patches.rst
says its ok to RESEND after a couple of weeks, but IMO that's overly aggressive
and just creates noise, e.g. your original patch was in my todo list, I just hadn't
gotten too it.  If you can't get a response after multiple pings, then by all means
RESEND, but in the future, please try pinging first.

For the patch context, there's no need to put "kvm" after patch, i.e. [PATCH], or
in this case [PATCH RESEND].  The "KVM:" namespace in the shortlog provides
sufficient context.

Regarding the shortlog, if a v2 is needed, ignore the somewhat messy history of
this file and use "KVM: x86:".

On Mon, Apr 10, 2023, alexjlzheng@gmail.com wrote:
> From: Jinliang Zheng <alexjlzheng@tencent.com>
> 
> According to the hardware manual, when the Poll command is issued, the
> byte returned by the I/O read is 1 in Bit 7 when there is an interrupt,
> and the highest priority binary code in Bits 2:0. The current pic
> simulation code is not implemented strictly according to the above
> expression.

There is way too much going on in this patch for this to be a sufficient description.
pic_intack() is not a direct replacement for the open coded logic in pic_poll_read(),
modulo the setting of bit 7.  E.g. there's no explanation for the "addr1 >> 7"
logic, pic_clear_isr() is conditionally called on auto_eoi, priority_add is now
modified, pic_update_irq() is no longer called, and so on and so forth.

Maybe the patch is correct and pic_poll_read() was completely broken, but if that's
the case, the changelog needs to be _much_ more verbose in explaining everything.

> Fix the implementation of poll mode in pic simulation by pic_intack,

Add () when referencing functions by name, i.e. pic_intack().

> and remove redundant pic_poll_read code.

Removing pic_poll() needs to be done in a separate patch.  Removing the helper
while simultaneously modifying its effective code makes the patch unnecessarily
difficult to review.

> Signed-off-by: Jinliang Zheng <alexjlzheng@tencent.com>
> ---
>  arch/x86/kvm/i8259.c | 29 ++++++-----------------------
>  1 file changed, 6 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
> index 4756bcb5724f..bc5b758e8f73 100644
> --- a/arch/x86/kvm/i8259.c
> +++ b/arch/x86/kvm/i8259.c
> @@ -397,35 +397,18 @@ static void pic_ioport_write(void *opaque, u32 addr, u32 val)
>  		}
>  }
>  
> -static u32 pic_poll_read(struct kvm_kpic_state *s, u32 addr1)
> -{
> -	int ret;
> -
> -	ret = pic_get_irq(s);
> -	if (ret >= 0) {
> -		if (addr1 >> 7) {
> -			s->pics_state->pics[0].isr &= ~(1 << 2);
> -			s->pics_state->pics[0].irr &= ~(1 << 2);
> -		}
> -		s->irr &= ~(1 << ret);
> -		pic_clear_isr(s, ret);
> -		if (addr1 >> 7 || ret != 2)
> -			pic_update_irq(s->pics_state);
> -	} else {
> -		ret = 0x07;
> -		pic_update_irq(s->pics_state);
> -	}
> -
> -	return ret;
> -}
> -
>  static u32 pic_ioport_read(void *opaque, u32 addr)
>  {
>  	struct kvm_kpic_state *s = opaque;
>  	int ret;
>  
>  	if (s->poll) {
> -		ret = pic_poll_read(s, addr);
> +		ret = pic_get_irq(s);
> +		if (ret >= 0) {
> +			pic_intack(s, ret);
> +			ret |= 0x80;
> +		} else

All branches in an if-elif-else statment need curly braces if any branch needs
statements (again, ignore the bad "prior art" in this file), i.e.

		if (ret >= 0) {
			...
		} else {
			ret = 0;
		}

> +			ret = 0;
>  		s->poll = 0;
>  	} else
>  		if ((addr & 1) == 0)
> -- 
> 2.37.3
> 

      reply	other threads:[~2023-04-10 16:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-10  3:10 [PATCH kvm RESEND] KVM: i8259: Fix poll command alexjlzheng
2023-04-10 16:32 ` 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=ZDQ6D6BX/3mqhCbW@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox