The blkio block driver will need to look up the file descriptor for a
given pointer. This is possible in softmmu builds where the memory API
is available for querying guest RAM.
Add stubs so tools like qemu-img that link the block layer still build
successfully. In this case there is no guest RAM
Avoid bounce buffers when QEMUIOVector elements are within previously
registered bdrv_register_buf() buffers.
The idea is that emulated storage controllers will register guest RAM
using bdrv_register_buf() and set the BDRV_REQ_REGISTERED_BUF on I/O
requests. Therefore no blkio_map_mem_region()
Register guest RAM using BlockRAMRegistrar and set the
BDRV_REQ_REGISTERED_BUF flag so block drivers can optimize memory
accesses in I/O requests.
This is for vdpa-blk, vhost-user-blk, and other I/O interfaces that rely
on DMA mapping/unmapping.
Signed-off-by: Stefan Hajnoczi
---
Emulated devices and other BlockBackend users wishing to take advantage
of blk_register_buf() all have the same repetitive job: register
RAMBlocks with the BlockBackend using RAMBlockNotifier.
Add a BlockRAMRegistrar API to do this. A later commit will use this
from hw/block/virtio-blk.c.
Block drivers may optimize I/O requests accessing buffers previously
registered with bdrv_register_buf(). Checking whether all elements of a
request's QEMUIOVector are within previously registered buffers is
expensive, so we need a hint from the user to avoid costly checks.
Add a
libblkio (https://gitlab.com/libblkio/libblkio/) is a library for
high-performance disk I/O. It currently supports io_uring and
virtio-blk-vhost-vdpa with additional drivers under development.
One of the reasons for developing libblkio is that other applications
besides QEMU can use it. This will
The only implementor of bdrv_register_buf() is block/nvme.c, where the
size is not needed when unregistering a buffer. This is because
util/vfio-helpers.c can look up mappings by address.
Future block drivers that implement bdrv_register_buf() may not be able
to do their job given only the buffer
When a RAMBlockNotifier is added, ->ram_block_added() is called with all
existing RAMBlocks. There is no equivalent ->ram_block_removed() call
when a RAMBlockNotifier is removed.
The util/vfio-helpers.c code (the sole user of RAMBlockNotifier) is fine
with this asymmetry because it does not rely
v3:
- Add virtio-blk-vhost-vdpa for vdpa-blk devices including VDUSE
- Add discard and write zeroes support
- Rebase and adopt latest libblkio APIs
v2:
- Add BDRV_REQ_REGISTERED_BUF to bs.supported_write_flags [Stefano]
- Use new blkioq_get_num_completions() API
- Implement .bdrv_refresh_limits()
For small disk images (<4 GiB), QEMU and SeaBIOS default to the
LARGE/ECHS disk translation method, but it is not uncommon for other
BIOS software to use LBA in these cases as well. Some operating
system boot loaders (e.g., NT 4) do not handle LARGE translations
outside of fixed configurations.
Hi
On Thu, Jul 7, 2022 at 4:13 PM Markus Armbruster wrote:
> marcandre.lur...@redhat.com writes:
>
> > From: Marc-André Lureau
> >
> > Remove monitor dependency from error printing code, by allowing programs
> > to set a callback for when to use "detailed" reporting or not.
> >
> >
Hi
On Thu, Jul 7, 2022 at 4:18 PM Markus Armbruster wrote:
> marcandre.lur...@redhat.com writes:
>
> > From: Marc-André Lureau
> >
> > error_vprintf() is implemented in monitor.c, which overrides the
> > default implementation from stubs/, while avoiding a direct dependency
> > to the monitor
Hi
On Thu, Jul 7, 2022 at 4:25 PM Markus Armbruster wrote:
> marcandre.lur...@redhat.com writes:
>
> > From: Marc-André Lureau
> >
> > Not needed outside monitor.c. Remove the needless stub.
> >
> > Signed-off-by: Marc-André Lureau
> > ---
> > include/monitor/monitor.h | 1 -
> >
On Thu, Jul 07, 2022 at 11:48:35AM -0400, John Snow wrote:
> On Thu, Jul 7, 2022 at 4:33 AM Daniel P. Berrangé wrote:
> >
> > On Thu, Jul 07, 2022 at 12:03:07AM -0400, John Snow wrote:
> > > The fedora container has since been split apart, so there's no suitable
> > > nearby target that would
On Thu, Jul 7, 2022 at 4:33 AM Daniel P. Berrangé wrote:
>
> On Thu, Jul 07, 2022 at 12:03:07AM -0400, John Snow wrote:
> > The fedora container has since been split apart, so there's no suitable
> > nearby target that would support "test-mingw" as it requires both x32
> > and x64 support -- so
On Thu, Jul 7, 2022 at 7:05 AM Richard Henderson
wrote:
>
> On 7/7/22 09:33, John Snow wrote:
> > 18.04 has fallen out of our support window, so move ubuntu.aarch64
> > forward to ubuntu 20.04, which is now our oldest supported Ubuntu
> > release.
>
> Ah. Squash with patch 5?
Can do. I left it
On Thu, Jul 7, 2022 at 4:40 AM Marc-André Lureau
wrote:
>
> Hi
>
> On Thu, Jul 7, 2022 at 8:10 AM John Snow wrote:
>>
>> In some container environments, there may be references to block devices
>> witnessable from a container through /proc/self/mountinfo that reference
>> devices we simply don't
Using the Parfait source code analyser and issue was found in
hw/nvme/ctrl.c where the macros NVME_CAP_SET_CMBS and NVME_CAP_SET_PMRS
are called with a ternary operatore in the second parameter, resulting
in a potentially unexpected expansion of the form:
x ? a: b & FLAG_TEST
which will result
marcandre.lur...@redhat.com writes:
> From: Marc-André Lureau
>
> Not needed outside monitor.c. Remove the needless stub.
>
> Signed-off-by: Marc-André Lureau
> ---
> include/monitor/monitor.h | 1 -
> monitor/monitor.c | 3 ++-
> stubs/error-printf.c | 5 -
> 3 files changed,
marcandre.lur...@redhat.com writes:
> From: Marc-André Lureau
>
> error_vprintf() is implemented in monitor.c, which overrides the
> default implementation from stubs/, while avoiding a direct dependency
> to the monitor from error-report.c.
>
> However, the stub solution isn't working when
marcandre.lur...@redhat.com writes:
> From: Marc-André Lureau
>
> Remove monitor dependency from error printing code, by allowing programs
> to set a callback for when to use "detailed" reporting or not.
>
> Signed-off-by: Marc-André Lureau
> ---
> include/qemu/error-report.h | 4 +++-
On 7/7/22 09:33, John Snow wrote:
18.04 has fallen out of our support window, so move ubuntu.aarch64
forward to ubuntu 20.04, which is now our oldest supported Ubuntu
release.
Ah. Squash with patch 5?
r~
Signed-off-by: John Snow
---
tests/vm/ubuntu.aarch64 | 14 +++---
1 file
On 7/7/22 09:33, John Snow wrote:
This checksum changes weekly; use a fixed point image and update the
checksum so we don't have to re-download it quite so much.
Note: Just like the centos.aarch64 test, this test currently seems very
flaky when run as a TCG test.
Signed-off-by: John Snow
---
On 7/7/22 13:42, Stefan Hajnoczi wrote:
The following changes since commit 8e9398e3b1a860b8c29c670c1b6c36afe8d87849:
Merge tag 'pull-ppc-20220706' of https://gitlab.com/danielhb/qemu into
staging (2022-07-07 06:21:05 +0530)
are available in the Git repository at:
Hi Iris
On [2022 Jul 06] Wed 19:16:26, Iris Chen wrote:
> Signed-off-by: Iris Chen
A couple of suggestions below if you would like to go for a v3 but otherwise:
Reviewed-by: Francisco Iglesias
Thanks,
Best regards,
Francisco Iglesias
> ---
> Addressing all comments.
> In reponse to this
On Thu, Jul 07, 2022 at 10:04:23AM +0100, Stefan Hajnoczi wrote:
>
>Does this patch solve the issue? The idea is to defer
>poll_set_started(false) for as long as possible.
Good idea! It is straightforward.
>
>diff --git a/util/aio-posix.c b/util/aio-posix.c
>index 731f3826c0..536f8b2534 100644
On Wed, Jul 06, 2022 at 10:12:14PM +0800, Chao Gao wrote:
> On Wed, Jul 06, 2022 at 12:59:29PM +0100, Stefan Hajnoczi wrote:
> >On Fri, Jul 01, 2022 at 05:13:48PM +0800, Chao Gao wrote:
> >> When measuring FIO read performance (cache=writethrough, bs=4k,
> >> iodepth=64) in
> >> VMs, we observe
On Thu, Jul 07, 2022 at 12:03:07AM -0400, John Snow wrote:
> The fedora container has since been split apart, so there's no suitable
> nearby target that would support "test-mingw" as it requires both x32
> and x64 support -- so either fedora-cross-win32 nor fedora-cross-win64
> would be truly
On Thu, Jul 07, 2022 at 12:03:06AM -0400, John Snow wrote:
> 18.04 has fallen out of our support window, so move ubuntu.aarch64
> forward to ubuntu 20.04, which is now our oldest supported Ubuntu
> release.
>
> Signed-off-by: John Snow
> ---
> tests/vm/ubuntu.aarch64 | 14 +++---
> 1
Hi
On Thu, Jul 7, 2022 at 8:10 AM John Snow wrote:
> In some container environments, there may be references to block devices
> witnessable from a container through /proc/self/mountinfo that reference
> devices we simply don't have access to in the container, and cannot
> provide information
The following changes since commit 8e9398e3b1a860b8c29c670c1b6c36afe8d87849:
Merge tag 'pull-ppc-20220706' of https://gitlab.com/danielhb/qemu into
staging (2022-07-07 06:21:05 +0530)
are available in the Git repository at:
https://gitlab.com/stefanha/qemu.git tags/block-pull-request
for
On Thu, Jul 07, 2022 at 12:03:04AM -0400, John Snow wrote:
> This is listed twice by accident; we require genisoimage to run the
> test, so remove the unconditional entry.
>
> Signed-off-by: John Snow
> Reviewed-by: Thomas Huth
> ---
> tests/vm/Makefile.include | 2 +-
> 1 file changed, 1
On Thu, Jul 07, 2022 at 12:03:03AM -0400, John Snow wrote:
> Ubuntu 18.04 is out of our support window, and Ubuntu 20.04 does not
> support i386 anymore. The debian project does, but they do not provide
> any cloud images for it, a new expect-style script would have to be
> written.
>
> Since we
On Thu, Jul 07, 2022 at 12:03:00AM -0400, John Snow wrote:
> The old CentOS image didn't work anymore because it was already EOL at
> the beginning of 2022.
>
> Signed-off-by: John Snow
> Reviewed-by: Thomas Huth
> ---
> tests/vm/centos | 6 +++---
> 1 file changed, 3 insertions(+), 3
On Thu, Jul 07, 2022 at 12:02:59AM -0400, John Snow wrote:
> If the initial setup fails, you've permanently altered the state of the
> downloaded image in an unknowable way. Use 'cp' like our other test
> setup scripts do.
>
> Signed-off-by: John Snow
> Reviewed-by: Thomas Huth
> ---
>
On Thu, Jul 07, 2022 at 12:02:58AM -0400, John Snow wrote:
> In some container environments, there may be references to block devices
> witnessable from a container through /proc/self/mountinfo that reference
> devices we simply don't have access to in the container, and cannot
> provide
On Thu, Jul 07, 2022 at 12:03:05AM -0400, John Snow wrote:
> If you try to run a 16 or 32 threaded test, you're going to run out of
> memory very quickly with qom-test and a few others. Bump the memory
> limit to try to scale with larger-core machines.
>
> Granted, this means that a 16 core
On Thu, Jul 07, 2022 at 12:03:02AM -0400, John Snow wrote:
> This checksum changes weekly; use a fixed point image and update the
> checksum so we don't have to re-download it quite so much.
>
> Note: Just like the centos.aarch64 test, this test currently seems very
> flaky when run as a TCG
Jens Axboe has confirmed that short reads are rare but can happen:
https://lore.kernel.org/io-uring/YsU%2FCGkl9ZXUI+Tj@stefanha-x1.localdomain/T/#m729963dc577d709b709c191922e98ec79d7eef54
The luring_resubmit_short_read() comment claimed they were only due to a
specific io_uring bug that was fixed
From: Dominique Martinet
sqeq.off here is the offset to read within the disk image, so obviously
not 'nread' (the amount we just read), but as the author meant to write
its current value incremented by the amount we just read.
Normally recent versions of linux will not issue short reads,
but it
On Thu, Jul 07, 2022 at 12:03:01AM -0400, John Snow wrote:
> Switch this test over to using a cloud image like the base CentOS8 VM
> test, which helps make this script a bit simpler too.
>
> Note: At time of writing, this test seems pretty flaky when run without
> KVM support for aarch64. Certain
On Wed, Jul 06, 2022 at 09:03:41AM +0100, Stefan Hajnoczi wrote:
> Jens Axboe has confirmed that short reads are rare but can happen:
> https://lore.kernel.org/io-uring/YsU%2FCGkl9ZXUI+Tj@stefanha-x1.localdomain/T/#m729963dc577d709b709c191922e98ec79d7eef54
>
> The luring_resubmit_short_read()
On Wed, Jul 06, 2022 at 09:03:41AM +0100, Stefan Hajnoczi wrote:
Jens Axboe has confirmed that short reads are rare but can happen:
https://lore.kernel.org/io-uring/YsU%2FCGkl9ZXUI+Tj@stefanha-x1.localdomain/T/#m729963dc577d709b709c191922e98ec79d7eef54
The luring_resubmit_short_read() comment
On Jun 28 14:22, Niklas Cassel wrote:
> Since commit 916b0f0b5264 ("hw/nvme: change nvme-ns 'shared' default")
> the default value of nvme-ns param 'shared' is set to true, regardless
> if there is a nvme-subsys node or not.
>
> On a system without a nvme-subsys node, a namespace will never be
44 matches
Mail list logo
