From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, Xu Yandong <xuyandong2@huawei.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org,
David Edmondson <david.edmondson@oracle.com>,
haibinzhang <haibinzhang@tencent.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Max Reitz <mreitz@redhat.com>,
Stefano Garzarella <sgarzare@redhat.com>
Subject: Re: [RFC PATCH v2 3/3] hw/block/pflash: use memory_region_init_rom_device_from_file()
Date: Tue, 2 Mar 2021 10:54:11 +0000 [thread overview]
Message-ID: <YD4ZU4LtM+P3IHVc@stefanha-x1.localdomain> (raw)
In-Reply-To: <bc4b3dee-4af4-7ce2-aeaa-70c0cfde679f@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
On Tue, Mar 02, 2021 at 08:04:46AM +0100, Philippe Mathieu-Daudé wrote:
> On 3/1/21 7:13 PM, Stefan Hajnoczi wrote:
> > On Mon, Mar 01, 2021 at 12:53:29PM +0100, Philippe Mathieu-Daudé wrote:
> > FWIW this API isn't perfect because the file could be reopened with QMP
> > and the existing mmap would remain in place.
>
> Can you show me a QMP example or point me at the command?
x-blockdev-change and other commands can reopen or reconfigure the
BlockDriverState graph - the mmap user would not be aware of this.
For example, block_set_io_throttle won't take effect if the guest has
the device mmapped.
> This shouldn't happen with the pflash.
It's not possible to say that because pflash has a
DEFINE_PROP_DRIVE("drive") property. The storage is backed by a
--drive/--blockdev and the user could send any QMP command that operates
on drives :(.
Users probably won't but there is nothing stopping them.
The block layer has a permission system (BLK_PERM_*). Maybe it's
possible to use it to lock a BDS while mmap is active?
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2021-03-02 10:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 11:53 [RFC PATCH v2 0/3] hw/block/pflash: Mmap read-only backend files with MAP_SHARED Philippe Mathieu-Daudé
2021-03-01 11:53 ` [RFC PATCH v2 1/3] exec/memory: Introduce memory_region_init_rom_device_from_file() Philippe Mathieu-Daudé
2021-03-01 11:53 ` [RFC PATCH v2 2/3] hw/block/pflash: Move code around Philippe Mathieu-Daudé
2021-03-01 11:53 ` [RFC PATCH v2 3/3] hw/block/pflash: use memory_region_init_rom_device_from_file() Philippe Mathieu-Daudé
2021-03-01 18:13 ` Stefan Hajnoczi
2021-03-02 7:04 ` Philippe Mathieu-Daudé
2021-03-02 10:54 ` Stefan Hajnoczi [this message]
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=YD4ZU4LtM+P3IHVc@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=armbru@redhat.com \
--cc=david.edmondson@oracle.com \
--cc=haibinzhang@tencent.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=xuyandong2@huawei.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.