All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: New Defects reported by Coverity Scan for XenProject
Date: Thu, 30 Jul 2026 15:14:00 +0200	[thread overview]
Message-ID: <d0ff411c-3bd9-4306-8782-ac63f7b202da@suse.com> (raw)
In-Reply-To: <6a6b266559168_35fb2bc1be9079a4147ab@prd-scan-dashboard-0.mail>

On 30.07.2026 12:24, scan-admin@coverity.com wrote:
> ** CID 1697485:       Control flow issues  (DEADCODE)
> /xen/arch/x86/hvm/hvm.c: 2436           in hvm_set_cr3()
> 
> 
> _____________________________________________________________________________________________
> *** CID 1697485:         Control flow issues  (DEADCODE)
> /xen/arch/x86/hvm/hvm.c: 2436             in hvm_set_cr3()
> 2430                 curr->arch.vm_event->write_data.cr3_noflush = noflush;
> 2431     
> 2432                 return X86EMUL_OKAY;
> 2433             }
> 2434         }
> 2435     
>>>>     CID 1697485:         Control flow issues  (DEADCODE)
>>>>     Execution cannot reach the expression "(value ^ curr->arch.hvm.guest_cr[3]) >> 12" inside this statement: "if (!!(curr->arch.hvm.guest...".
> 2436         if ( hvm_paging_enabled(curr) && paging_mode_shadow(currd) &&
> 2437              ((value ^ curr->arch.hvm.guest_cr[3]) >> PAGE_SHIFT) )
> 2438         {
> 2439             /* Shadow-mode CR3 change. Check PDBR and update refcounts. */
> 2440             struct page_info *page;
> 2441     
> 
> ** CID 1697484:       Control flow issues  (DEADCODE)
> /xen/arch/x86/hvm/svm/svm.c: 128           in svm_update_guest_cr()
> 
> 
> _____________________________________________________________________________________________
> *** CID 1697484:         Control flow issues  (DEADCODE)
> /xen/arch/x86/hvm/svm/svm.c: 128             in svm_update_guest_cr()
> 122                      monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
> 123                    vmcb_set_cr_intercepts(vmcb, intercepts | CR_INTERCEPT_CR3_WRITE);
> 124             }
> 125     
> 126             value = v->arch.hvm.guest_cr[0];
> 127             if ( paging_mode_shadow(v->domain) )
>>>>     CID 1697484:         Control flow issues  (DEADCODE)
>>>>     Execution cannot reach this statement: "value |= 0x80010000UL;".
> 128                 value |= X86_CR0_PG | X86_CR0_WP;
> 129             vmcb_set_cr0(vmcb, value);
> 130             break;
> 131     
> 132         case 2:
> 133             vmcb_set_cr2(vmcb, v->arch.hvm.guest_cr[2]);
> 
> ** CID 1697483:       Control flow issues  (DEADCODE)
> /xen/arch/x86/hvm/svm/svm.c: 396           in svm_vmcb_restore()
> 
> 
> _____________________________________________________________________________________________
> *** CID 1697483:         Control flow issues  (DEADCODE)
> /xen/arch/x86/hvm/svm/svm.c: 396             in svm_vmcb_restore()
> 390                 return -EINVAL;
> 391             }
> 392         }
> 393     
> 394         if ( paging_mode_shadow(v->domain) )
> 395         {
>>>>     CID 1697483:         Control flow issues  (DEADCODE)
>>>>     Execution cannot reach this statement: "if (c->cr0 & 0x80000000UL) ...".
> 396             if ( c->cr0 & X86_CR0_PG )
> 397             {
> 398                 page = get_page_from_gfn(v->domain, c->cr3 >> PAGE_SHIFT,
> 399                                          NULL, P2M_ALLOC);
> 400                 if ( !page )
> 401                 {
> 
> ** CID 1697482:         (DEADCODE)
> /xen/arch/x86/hvm/hvm.c: 2332           in hvm_set_cr0()
> /xen/arch/x86/hvm/hvm.c: 2382           in hvm_set_cr0()
> 
> 
> _____________________________________________________________________________________________
> *** CID 1697482:           (DEADCODE)
> /xen/arch/x86/hvm/hvm.c: 2332             in hvm_set_cr0()
> 2326                 hvm_update_guest_efer(v);
> 2327             }
> 2328     
> 2329             if ( paging_mode_shadow(d) )
> 2330             {
> 2331                 /* The guest CR3 must be pointing to the guest physical. */
>>>>     CID 1697482:           (DEADCODE)
>>>>     Execution cannot reach this statement: "gfn = v->arch.hvm.guest_cr[...".
> 2332                 gfn = v->arch.hvm.guest_cr[3] >> PAGE_SHIFT;
> 2333                 page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
> 2334                 if ( !page )
> 2335                 {
> 2336                     gdprintk(XENLOG_ERR, "Invalid CR3 value = %lx\n",
> 2337                              v->arch.hvm.guest_cr[3]);
> /xen/arch/x86/hvm/hvm.c: 2382             in hvm_set_cr0()
> 2376                 v->arch.hvm.guest_efer &= ~EFER_LMA;
> 2377                 hvm_update_guest_efer(v);
> 2378             }
> 2379     
> 2380             if ( paging_mode_shadow(d) )
> 2381             {
>>>>     CID 1697482:           (DEADCODE)
>>>>     Execution cannot reach this statement: "put_page((struct page_info ...".
> 2382                 put_page(pagetable_get_page(v->arch.guest_table));
> 2383                 v->arch.guest_table = pagetable_null();
> 2384             }
> 2385         }
> 2386     
> 2387         if ( ((value ^ old_value) & X86_CR0_CD) &&

For all of the above (and maybe more further down the original report): Do we have
control over the .config Coverity uses? These (not really) issues all result from
SHADOW_PAGING=n by default now, i.e. the unreachable statements are expected in
that configuration (and they were there before, if the build had been done with
SHADOW_PAGING=n).

Jan


       reply	other threads:[~2026-07-30 13:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6a6b266559168_35fb2bc1be9079a4147ab@prd-scan-dashboard-0.mail>
2026-07-30 13:14 ` Jan Beulich [this message]
2026-07-30 13:21   ` New Defects reported by Coverity Scan for XenProject Andrew Cooper
2026-07-30 14:39     ` Jan Beulich
     [not found] <6a3bce99e5494_767442bc3001679a440720@prd-scan-dashboard-0.mail>
2026-06-24 13:04 ` Jan Beulich
2026-06-24 21:53   ` Jason Andryuk
2026-06-25  5:56     ` Jan Beulich
2026-06-24 13:12 ` Jan Beulich
     [not found] <6922db67d5bee_ec6942e9307a67994398e5@prd-scan-dashboard-0.mail>
2025-11-24  8:37 ` Jan Beulich
     [not found] <68bd98b92c2b2_2afba52d9ed55e79908873e@prd-scan-dashboard-0.mail>
2025-09-08 10:19 ` Jan Beulich
2025-09-08 11:04   ` Alejandro Vallejo
2025-09-08 11:25     ` Jan Beulich
2025-09-08 12:48       ` Alejandro Vallejo
2025-09-08 13:17         ` Jan Beulich
     [not found] <68b9a73be8eb_27ea7e2d9ed55e799088716@prd-scan-dashboard-0.mail>
2025-09-04 14:54 ` Jan Beulich
     [not found] <67f26722e020c_13a342abaf9ddd9a0513e7@prd-scan-dashboard-0.mail>
2025-04-07  7:26 ` Jan Beulich
2025-04-07  7:43   ` Andrew Cooper
     [not found] <67ed34047fd3c_1209992cc92a0f99a0989e0@prd-scan-dashboard-0.mail>
2025-04-02 14:19 ` Jan Beulich
2025-04-02 16:01   ` Andrew Cooper
     [not found] <664dc165759df_5e9362b92d249399c762@prd-scan-dashboard-0.mail>
2024-05-22 10:05 ` Jan Beulich
2024-05-22 13:49   ` Andrew Cooper
     [not found] <6637576caf98c_10d9e42c57d37559ac60499@prd-scan-dashboard-0.mail>
2024-05-06  7:46 ` Jan Beulich
     [not found] <6547674e54da3_1c3af2c62521719a8359bc@prd-scan-dashboard-0.mail>
2023-11-06  7:36 ` Jan Beulich
     [not found] <64859cf3a1e46_712752abb10eab98834b9@prd-scan-dashboard-0.mail>
2023-06-12 10:54 ` Jan Beulich
2023-06-12 11:06   ` Andrew Cooper
     [not found] <600d4d7f99bc3_241662b17c874cf6097f1@prd-scan-dashboard-0.mail>
2021-01-25 10:14 ` Jan Beulich
     [not found] <5700f7b3e7d5c_3fdf4db3186252@ss1435.mail>
2016-04-04 15:07 ` Ian Jackson
     [not found] <56ce8ad13abd2_bd9abd33094410@ss1435.mail>
2016-02-25 10:00 ` Ian Campbell
2016-02-25 10:06   ` George Dunlap
     [not found] <551be9e0474d8_2970d1331454394@scan.coverity.com.mail>
2015-04-02 14:32 ` Ian Campbell
2015-04-02 15:43   ` Charles Arnold
     [not found] <E1Vgaam-0000UH-GS@build-l3.scan.coverity.com>
2013-11-13 13:51 ` Ian Campbell
2013-11-13 14:01   ` David Vrabel

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=d0ff411c-3bd9-4306-8782-ac63f7b202da@suse.com \
    --to=jbeulich@suse.com \
    --cc=xen-devel@lists.xenproject.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.