xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>, Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Varad Gautam" <vrd@amazon.de>,
	"Ian Jackson" <ian.jackson@eu.citrix.com>,
	"Hongyan Xia" <hongyxia@amazon.com>,
	xen-devel@lists.xenproject.org,
	"Paul Durrant" <pdurrant@amazon.co.uk>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 7/8] x86/setup: simplify handling of initrdidx when no initrd present
Date: Wed, 26 Feb 2020 09:37:45 +0100	[thread overview]
Message-ID: <ddea05a7-645f-42d5-43f7-ddf008cdb9cb@suse.com> (raw)
In-Reply-To: <863e5864-5aef-3fde-9433-bc4f8bd19eb2@xen.org>

On 26.02.2020 08:13, Julien Grall wrote:
> On 25/02/2020 12:34, Jan Beulich wrote:
>> Further, even if all current implementations obeyed by the more
>> strict rule, this still wouldn't mean callers are actually permitted
>> to assume such. The more strict rule would then also need to be
>> written down, such that it won't get violated again in the future
>> (by changes to an existing arch's implementation, or by a new port
> 
> To be honest, the rule should be written down in any case. The current 
> one is not necessarily an obvious one and also differ from what Linux 
> folks can expect.

I think we should stick to the more relaxed rule in any event, unless
there's a strong reason to enforce the more strict one. Much (but not
all) of Linux code looks to assume the more relaxed rule too, likely
also for historical reasons (when the implementation on e.g. x86-64
still followed the more relaxed model).

> Regarding future port, the number of architectures in Linux using custom 
> bitops are fairly limited (AFAICT only arm32 and unicore32). All the 
> rest (including x86) using a generic implementation.
> 
> On Xen, Arm64 is already using the generic implementation. Is there any 
> particular concern to use it for x86 as well?

According to the (over 10 years old) commit updating Linux x86 this
way, the generic implementation was even faster. If that was the
case today and for our implementation as well, then I think it
would be very nice if we updated. If, otoh, data isn't as clear,
then further consideration may be needed. Andrew, do you have any
thoughts either way?

> If not, I can pull a patch to use the generic implementation on 
> x86/arm32. This would solve the discrenpancies in find_*_bit 
> implementations.

This is orthogonal to the issue discussed - as said, I think code
using the functions would still better assume the more relaxed model.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-02-26  8:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-01  0:32 [Xen-devel] [PATCH 0/8] Early cleanups and bug fixes in preparation for live update David Woodhouse
2020-02-01  0:32 ` [Xen-devel] [PATCH 1/8] x86/smp: reset x2apic_enabled in smp_send_stop() David Woodhouse
2020-02-03 16:18   ` Roger Pau Monné
2020-02-01  0:32 ` [Xen-devel] [PATCH 2/8] x86/setup: Fix badpage= handling for memory above HYPERVISOR_VIRT_END David Woodhouse
2020-02-03 10:57   ` Julien Grall
2020-02-20 15:38   ` Jan Beulich
2020-03-06 22:52   ` Julien Grall
2020-02-01  0:32 ` [Xen-devel] [PATCH 3/8] x86/setup: Don't skip 2MiB underneath relocated Xen image David Woodhouse
2020-02-01  0:32 ` [Xen-devel] [PATCH 4/8] xen/vmap: allow vm_init_type to be called during early_boot David Woodhouse
2020-02-13 10:36   ` Julien Grall
2020-02-21 16:42   ` Jan Beulich
2020-02-01  0:33 ` [Xen-devel] [PATCH 5/8] xen/vmap: allow vmap() to be called during early boot David Woodhouse
2020-02-03 14:00   ` Julien Grall
2020-02-03 16:37     ` David Woodhouse
2020-02-04 11:00       ` George Dunlap
2020-02-04 11:06         ` David Woodhouse
2020-02-04 11:18           ` David Woodhouse
2020-02-09 18:19       ` Julien Grall
2020-02-21 16:46   ` Jan Beulich
2020-02-01  0:33 ` [Xen-devel] [PATCH 6/8] x86/setup: move vm_init() before end_boot_allocator() David Woodhouse
2020-02-03 11:10   ` Xia, Hongyan
2020-02-03 14:03     ` David Woodhouse
2020-02-21 16:48   ` Jan Beulich
2020-02-01  0:33 ` [Xen-devel] [PATCH 7/8] x86/setup: simplify handling of initrdidx when no initrd present David Woodhouse
2020-02-13 10:47   ` Julien Grall
2020-02-21 16:59   ` Jan Beulich
2020-02-24 13:31     ` Julien Grall
2020-02-25 12:34       ` Jan Beulich
2020-02-26  7:13         ` Julien Grall
2020-02-26  8:37           ` Jan Beulich [this message]
2020-02-01  0:33 ` [Xen-devel] [PATCH 8/8] x86/setup: lift dom0 creation out into create_dom0() function David Woodhouse
2020-02-03 14:28   ` Julien Grall
2020-02-03 15:03     ` David Woodhouse
2020-02-21 17:06   ` Jan Beulich
2020-03-17 23:45     ` David Woodhouse

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=ddea05a7-645f-42d5-43f7-ddf008cdb9cb@suse.com \
    --to=jbeulich@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dwmw2@infradead.org \
    --cc=hongyxia@amazon.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=pdurrant@amazon.co.uk \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=vrd@amazon.de \
    --cc=wl@xen.org \
    --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 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).