From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Kevin Tian <kevin.tian@intel.com>,
sstabellini@kernel.org, Jan Beulich <jbeulich@suse.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
Liu Jinsong <jinsong.liu@alibaba-inc.com>,
Christoph Egger <chegger@amazon.de>, Tim Deegan <tim@xen.org>,
xen-devel@lists.xen.org, Julien Grall <julien.grall@arm.com>,
Paul Durrant <paul.durrant@citrix.com>,
Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v6 03/14] xen: Use a typesafe to define INVALID_MFN
Date: Fri, 8 Jul 2016 17:21:00 -0700 [thread overview]
Message-ID: <20160709002100.GB12494@localhost.localdomain> (raw)
In-Reply-To: <2f7cc943-38ab-394d-2ab5-c3b61850ed07@citrix.com>
On Fri, Jul 08, 2016 at 08:20:03PM +0100, Andrew Cooper wrote:
> On 08/07/2016 23:01, Elena Ufimtseva wrote:
> >
> >>> @@ -838,7 +838,6 @@ mfn_t oos_snapshot_lookup(struct domain *d, mfn_t gmfn)
> >>>
> >>> SHADOW_ERROR("gmfn %lx was OOS but not in hash table\n", mfn_x(gmfn));
> >>> BUG();
> >>> - return _mfn(INVALID_MFN);
> > Can compiler be unhappy about this?
>
> This was my suggestion, from a previous round of review.
Ah! Thanks for explanation.
>
> A while ago, I annotated BUG() with unreachable(), as as execution will
> not continue from a bugframe, but the shadow code is definitely older
> than my change.
>
> As such, compilers will have been dropping this return statement as part
> of dead-code-elimination anyway.
>
> This option is better than just replacing one bit of dead code with a
> different bit of dead code.
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-07-09 0:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-06 13:00 [PATCH v6 00/14] xen/arm: Use the typesafes gfn and mfn Julien Grall
2016-07-06 13:01 ` [PATCH v6 01/14] xen: Use the typesafe mfn and gfn in map_mmio_regions Julien Grall
2016-07-06 13:01 ` [PATCH v6 02/14] xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN Julien Grall
2016-07-06 13:01 ` [PATCH v6 03/14] xen: Use a typesafe to define INVALID_MFN Julien Grall
2016-07-06 13:04 ` Julien Grall
2016-07-08 22:01 ` Elena Ufimtseva
2016-07-08 19:20 ` Andrew Cooper
2016-07-09 0:21 ` Elena Ufimtseva [this message]
2016-07-08 19:39 ` Julien Grall
2016-07-06 13:01 ` [PATCH v6 04/14] xen: Use a typesafe to define INVALID_GFN Julien Grall
2016-07-06 13:05 ` Julien Grall
2016-07-08 22:05 ` Elena Ufimtseva
2016-07-06 13:01 ` [PATCH v6 05/14] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn Julien Grall
2016-07-06 13:01 ` [PATCH v6 06/14] xen/arm: Rework the interface of p2m_cache_flush and use typesafe gfn Julien Grall
2016-07-06 13:01 ` [PATCH v6 07/14] xen/arm: map_regions_rw_cache: Map the region with p2m->default_access Julien Grall
2016-07-06 13:01 ` [PATCH v6 08/14] xen/arm: dom0_build: Remove dead code in allocate_memory Julien Grall
2016-07-06 13:01 ` [PATCH v6 09/14] xen/arm: p2m: Remove unused operation ALLOCATE Julien Grall
2016-07-06 13:01 ` [PATCH v6 10/14] xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region Julien Grall
2016-07-06 13:01 ` [PATCH v6 11/14] xen/arm: Use the typesafes mfn and gfn in map_regions_rw_cache Julien Grall
2016-07-06 13:01 ` [PATCH v6 12/14] xen/arm: p2m: Introduce helpers to insert and remove mapping Julien Grall
2016-07-11 16:16 ` Julien Grall
2016-07-06 13:01 ` [PATCH v6 13/14] xen/arm: p2m: Use typesafe gfn for {max, lowest}_mapped_gfn Julien Grall
2016-07-06 13:01 ` [PATCH v6 14/14] xen/arm: p2m: Rework the interface of apply_p2m_changes and use typesafe Julien Grall
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=20160709002100.GB12494@localhost.localdomain \
--to=elena.ufimtseva@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=chegger@amazon.de \
--cc=george.dunlap@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=jinsong.liu@alibaba-inc.com \
--cc=julien.grall@arm.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=paul.durrant@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.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;
as well as URLs for NNTP newsgroup(s).