All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: oe-kbuild-all@lists.linux.dev, David Woodhouse <dwmw@amazon.co.uk>
Subject: [dwmw2:xen-v2 8/10] arch/x86/kvm/xen.c:676:79: warning: right shift count >= width of type
Date: Fri, 07 Aug 2026 15:24:45 +0800	[thread overview]
Message-ID: <202608071502.rYOi3Pg8-lkp@intel.com> (raw)

tree:   git://git.infradead.org/users/dwmw2/linux xen-v2
head:   e8c3b5bdc2b164cc8134a0cb30a58ba7d7b49351
commit: b363d2ca18aaa6cecced31654605577f66ef6d95 [8/10] KVM: x86/xen: Use 32-bit atomics if vCPU's evtchn_pending_sel isn't aligned
config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20260807/202608071502.rYOi3Pg8-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260807/202608071502.rYOi3Pg8-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202608071502.rYOi3Pg8-lkp@intel.com/

All warnings (new ones prefixed by >>):

   arch/x86/kvm/xen.c: In function 'kvm_xen_inject_pending_events':
>> arch/x86/kvm/xen.c:676:79: warning: right shift count >= width of type [-Wshift-count-overflow]
     676 |                                        [src_hi] "r" ((u32)(evtchn_pending_sel >> 32)));
         |                                                                               ^~


vim +676 arch/x86/kvm/xen.c

   630	
   631	/*
   632	 * On event channel delivery, the vcpu_info may not have been accessible.
   633	 * In that case, there are bits in vcpu->arch.xen.evtchn_pending_sel which
   634	 * need to be marked into the vcpu_info (and evtchn_upcall_pending set).
   635	 * Do so now that we can sleep in the context of the vCPU to bring the
   636	 * page in, and refresh the pfn cache for it.
   637	 */
   638	void kvm_xen_inject_pending_events(struct kvm_vcpu *v)
   639	{
   640		unsigned long evtchn_pending_sel = READ_ONCE(v->arch.xen.evtchn_pending_sel);
   641		struct gfn_to_pfn_cache *gpc = &v->arch.xen.vcpu_info_cache;
   642		unsigned long flags;
   643	
   644		if (!evtchn_pending_sel)
   645			return;
   646	
   647		/*
   648		 * Yes, this is an open-coded loop. But that's just what put_user()
   649		 * does anyway. Page it in and retry the instruction. We're just a
   650		 * little more honest about it.
   651		 */
   652		read_lock_irqsave(&gpc->lock, flags);
   653		while (!kvm_gpc_check(gpc, sizeof(struct vcpu_info))) {
   654			read_unlock_irqrestore(&gpc->lock, flags);
   655	
   656			if (kvm_gpc_refresh(gpc, sizeof(struct vcpu_info)))
   657				return;
   658	
   659			read_lock_irqsave(&gpc->lock, flags);
   660		}
   661	
   662		/* Now gpc->khva is a valid kernel address for the vcpu_info */
   663		if (kvm_xen_has_64bit_shinfo(v->kvm)) {
   664			struct vcpu_info *vi = gpc->khva;
   665	
   666			if (IS_ALIGNED((unsigned long)&vi->evtchn_pending_sel, sizeof(u64)))
   667				asm volatile(LOCK_PREFIX "orq %[src], %[dst]\n"
   668					     : [dst] "+m" (vi->evtchn_pending_sel)
   669					     : [src] "r" (evtchn_pending_sel));
   670			else
   671				asm volatile(LOCK_PREFIX "orl %[src_lo], %[dst_lo]\n"
   672					     LOCK_PREFIX "orl %[src_hi], %[dst_hi]\n"
   673					     : [dst_lo] "+m" (vi->evtchn_pending_sel),
   674					       [dst_hi] "+m" (*(((u32 *)&vi->evtchn_pending_sel) + 1))
   675					     : [src_lo] "r" ((u32)evtchn_pending_sel),
 > 676					       [src_hi] "r" ((u32)(evtchn_pending_sel >> 32)));
   677	
   678			asm volatile(LOCK_PREFIX "andq %1, %0\n"
   679				     : "+m" (v->arch.xen.evtchn_pending_sel)
   680				     : "r" (~evtchn_pending_sel));
   681			WRITE_ONCE(vi->evtchn_upcall_pending, 1);
   682		} else {
   683			u32 evtchn_pending_sel32 = evtchn_pending_sel;
   684			struct compat_vcpu_info *vi = gpc->khva;
   685	
   686			asm volatile(LOCK_PREFIX "orl %0, %1\n"
   687				     "notl %0\n"
   688				     LOCK_PREFIX "andl %0, %2\n"
   689				     : "=r" (evtchn_pending_sel32),
   690				       "+m" (vi->evtchn_pending_sel),
   691				       "+m" (v->arch.xen.evtchn_pending_sel)
   692				     : "0" (evtchn_pending_sel32));
   693			WRITE_ONCE(vi->evtchn_upcall_pending, 1);
   694		}
   695	
   696		kvm_gpc_mark_dirty_in_slot(gpc);
   697		read_unlock_irqrestore(&gpc->lock, flags);
   698	
   699		/* For the per-vCPU lapic vector, deliver it as MSI. */
   700		if (v->arch.xen.upcall_vector)
   701			kvm_xen_inject_vcpu_vector(v);
   702	}
   703	

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

                 reply	other threads:[~2026-08-07  7:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=202608071502.rYOi3Pg8-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=seanjc@google.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.