From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Jingqi Liu" <jingqi.liu@intel.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Ján Tomko" <jtomko@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2 2/2] mmap-alloc: Include osdep.h before checking CONFIG_LINUX
Date: Mon, 16 Mar 2020 17:41:02 -0400 [thread overview]
Message-ID: <20200316173626-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAFEAcA-i_S1TZWoDQ5L4J32t3N+aHWvm9dGqHxFHB7wuKpE0iA@mail.gmail.com>
On Mon, Mar 16, 2020 at 07:20:02PM +0000, Peter Maydell wrote:
> On Mon, 16 Mar 2020 at 18:40, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >
> > On Mon, Mar 16, 2020 at 06:08:54PM +0000, Peter Maydell wrote:
> > > The usual approach is that if you don't have the Linux-specific
> > > feature available you quietly fall back to whatever the sensible
> > > behaviour is for when the feature isn't present. We definitely
> > > don't want to be printing warnings on non-Linux systems that
> > > are effectively just saying "you're not running Linux". Same goes
> > > for "host happens not to be running a bleeding-edge Linux kernel
> > > and this feature isn't available yet".
> >
> > I don't think using pmem=on without MAP_SYNC is expected to be a
> > supported use case, is it? If a use case is not supported, the
> > sensible behavior is to tell the user it is not supported.
>
> Yeah, that's fair. But the code at the moment does a fallback
> to "proceed without SHARED_VALIDATE | SYNC", so I assumed it
> was supposed to work.
>
> thanks
> -- PMM
Oh I remember now. pmem=on was introduced without MAP_SYNC first.
So yes, it's ok to set it to 0 for mips.
--
MST
next prev parent reply other threads:[~2020-03-16 22:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 23:23 [PATCH v2 0/2] Fix MAP_SYNC support when host has older glibc version Eduardo Habkost
2020-03-11 23:23 ` [PATCH v2 1/2] Use -isystem for linux-headers dir Eduardo Habkost
2020-03-12 6:29 ` Michael S. Tsirkin
2020-03-12 10:17 ` Peter Maydell
2020-03-11 23:23 ` [PATCH v2 2/2] mmap-alloc: Include osdep.h before checking CONFIG_LINUX Eduardo Habkost
2020-03-12 6:30 ` Michael S. Tsirkin
2020-03-15 15:45 ` Eduardo Habkost
2020-03-15 21:15 ` Michael S. Tsirkin
2020-03-16 17:30 ` Eduardo Habkost
2020-03-16 18:08 ` Peter Maydell
2020-03-16 18:40 ` Eduardo Habkost
2020-03-16 19:08 ` Michael S. Tsirkin
2020-03-16 19:20 ` Peter Maydell
2020-03-16 21:41 ` Michael S. Tsirkin [this message]
2020-03-12 0:25 ` [PATCH v2 0/2] Fix MAP_SYNC support when host has older glibc version no-reply
2020-03-14 9:39 ` Paolo Bonzini
2020-03-15 15:46 ` Eduardo Habkost
2020-03-15 21:18 ` Michael S. Tsirkin
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=20200316173626-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jingqi.liu@intel.com \
--cc=jtomko@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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.