On Dec 9 10:57, Klaus Jensen wrote:
> Hi Dmitry,
>
> By and large, this looks OK to me. There are still some issues here and
> there, and some comments of mine that you did not address, but I will
> follow up with patches to fix that. Let's get this merged.
>
> It looks like the nvme-next you re
On 1/7/21 8:24 PM, - wrote:
> Public bug reported:
>
> The patch discussed here:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg720833.html
> introduces an artificial size constraint for SD cards
> that has no relation to reality.
>
> I'm trying to use an _actual_ **physical** SD card,
>
On Thu, Jan 07, 2021 at 09:05:42AM +0100, Peter Krempa wrote:
> On Tue, Jan 05, 2021 at 15:12:55 +0100, Peter Krempa wrote:
> > On Mon, Jan 04, 2021 at 15:30:19 -0500, Masayoshi Mizuma wrote:
> > > On Sat, Dec 19, 2020 at 11:30:39PM -0500, Masayoshi Mizuma wrote:
>
> [...]
>
> > {"execute":
On Tue, Sep 15, 2020 at 2:51 PM Stefan Reiter wrote:
>
> On 9/15/20 11:08 AM, Nir Soffer wrote:
> > On Mon, Sep 14, 2020 at 3:25 PM Stefan Reiter wrote:
> >>
> >> Hi list,
> >>
> >> following command fails since 5.1 (tested on kernel 5.4.60):
> >>
> >> # qemu-img convert -p -f raw -O raw /dev/zvo
Il gio 7 gen 2021, 20:36 Roman Bolshakov ha scritto:
> > No I think that Meson should simply explode link_whole libraries to their
> > constituent objects. This way duplicates are avoided.
> >
>
> Ok. I've looked through related changes in meson and it flattens object
> files implicitly for link
On Thu, Jan 07, 2021 at 07:22:06PM +0100, Paolo Bonzini wrote:
> On 07/01/21 19:18, Roman Bolshakov wrote:
> >
> > > The real issue is that Meson's implementation of link_whole for
> > > library-in-library makes sense for one use case (convenience library that
> > > is
> > > linked into another c
On 07/01/21 19:18, Roman Bolshakov wrote:
The real issue is that Meson's implementation of link_whole for
library-in-library makes sense for one use case (convenience library that is
linked into another convenience library) but not for another (grouping code
for subsystems). I cannot blame the
On Thu, Jan 07, 2021 at 05:23:54PM +0100, Paolo Bonzini wrote:
> On 07/01/21 16:56, Roman Bolshakov wrote:
> > IMO duplication of dependencies shouldn't be needed for a build system.
> > Meta build system should allow private and public dependencies. Different
> > rules are applied to them. Private
Ugh, please ignore this one. I didn't remove the test changes, but the
tests passed, which I don't understand.
On Thursday, 2021-01-07 at 17:55:38 GMT, David Edmondson wrote:
> When a call to fcntl(2) for the purpose of manipulating file locks
> fails with an error other than EAGAIN or EACCES, re
When a call to fcntl(2) for the purpose of manipulating file locks
fails with an error other than EAGAIN or EACCES, report the error
returned by fcntl.
EAGAIN or EACCES are elided as they are considered to be common
failures, indicating that a conflicting lock is held by another
process.
Signed-o
On 07/01/21 16:56, Roman Bolshakov wrote:
IMO duplication of dependencies shouldn't be needed for a build system.
Meta build system should allow private and public dependencies. Different
rules are applied to them. Private dependency is not propagated beyond a
target that uses it, public dependen
On Thu, Jan 07, 2021 at 12:41:40PM +0100, Paolo Bonzini wrote:
> On 05/01/21 15:37, Roman Bolshakov wrote:
> > Does it work if you do:
> >
> > crypto_ss.add(authz, qom)
> > libcrypto = static_library('crypto', crypto_ss.sources() + genh,
> > dependencies: crypto_ss.depe
On 17.12.20 17:56, Maxim Levitsky wrote:
When the device doesn't support the VPD block limits page, we emulate it even
for SCSI passthrough.
As a part of the emulation we need to add it to the 'Supported VPD Pages'
The code that does this adds it to the page, but it doesn't increase the length
On 17.12.20 17:56, Maxim Levitsky wrote:
Switch file-posix to expose only the max_ioctl_transfer limit.
Let the iscsi driver work as it did before since it is bound by the transfer
limit in both regular read/write and in SCSI passthrough case.
Switch the scsi-disk and scsi-block drivers to read
On 17.12.20 17:56, Maxim Levitsky wrote:
Maximum transfer size when accessing a kernel block device is only relevant
when using SCSI passthrough (SG_IO ioctl) since only in this case the requests
are passed directly to underlying hardware with no pre-processing.
So by “with no pre-processing” y
On Mon, 2020-11-16 at 15:48 +0100, Kevin Wolf wrote:
> Am 11.11.2020 um 16:39 hat Maxim Levitsky geschrieben:
> > On Linux, fallocate(fd, FALLOC_FL_PUNCH_HOLE) when it is used on a block
> > device,
> > without O_DIRECT can return -EBUSY if it races with another write to the
> > same page.
> >
>
On 17.12.20 17:56, Maxim Levitsky wrote:
From: Tom Yan
sg devices have different major/minor than their corresponding
block devices. Using sysfs to get max segments never really worked
for them.
Fortunately the sg driver provides an ioctl to get sg_tablesize,
which is apparently equivalent to
On 17.12.20 17:56, Maxim Levitsky wrote:
From: Tom Yan
We can and should get max transfer length and max segments for all host
devices / cdroms (on Linux).
Also use MIN_NON_ZERO instead when we clamp max transfer length against
max segments.
Signed-off-by: Tom Yan
Signed-off-by: Maxim Levits
On Thu, Jan 07, 2021 at 10:56:12AM +, Richard W.M. Jones wrote:
> On Thu, Jan 07, 2021 at 09:58:17AM +, Richard W.M. Jones wrote:
> > On Fri, Dec 04, 2020 at 01:27:13AM +0300, Vladimir Sementsov-Ogievskiy
> > wrote:
> > > Finally to be safe with calculations, to not calculate different
> >
On 05/01/21 15:37, Roman Bolshakov wrote:
Does it work if you do:
crypto_ss.add(authz, qom)
libcrypto = static_library('crypto', crypto_ss.sources() + genh,
dependencies: crypto_ss.dependencies(),
...)
crypto = declare_dependency(link_whole
On Thu, Jan 07, 2021 at 09:58:17AM +, Richard W.M. Jones wrote:
> On Fri, Dec 04, 2020 at 01:27:13AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> > Finally to be safe with calculations, to not calculate different
> > maximums for different nodes (depending on cluster size and
> > request_alignm
On Thu, 2020-12-17 at 18:56 +0200, Maxim Levitsky wrote:
> This patch series attempts to provide a solution to the problem of the
> transfer
> limits of the raw file driver (host_device/file-posix), some of which I
> already tried to fix in the past.
>
> I included 2 patches from Tom Yan which fi
On 07/01/21 10:10, Philippe Mathieu-Daudé wrote:
libblock.fa(block_io.c.o): In function `stat64_max':
include/qemu/stats64.h:58: undefined reference to `__atomic_load_8'
include/qemu/stats64.h:60: undefined reference to
`__atomic_compare_exchange_8'
libblock.fa(block_qapi.c.o): In function `stat6
On Thu, 2020-12-17 at 19:09 +0200, Maxim Levitsky wrote:
> Use the bdrv_co_delete_file interface to delete the underlying
> file if qcow2 initialization fails (e.g due to bad encryption secret)
>
> This makes the qcow2 driver behave the same way as the luks driver behaves.
>
> Buglink: https://bu
On Fri, Dec 04, 2020 at 01:27:13AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Finally to be safe with calculations, to not calculate different
> maximums for different nodes (depending on cluster size and
> request_alignment), let's simply set QEMU_ALIGN_DOWN(INT64_MAX, 2^30)
> as absolute maximu
Cc'ing atomic team and qemu-block@ for "qemu/stats64.h".
On 1/7/21 9:40 AM, Philippe Mathieu-Daudé wrote:
> Public bug reported:
>
> As of commit 50536341b47, using --enable-sanitizers on 32-bit Linux host:
> - displays various warnings
> - fails linking
>
> Using Ubuntu 18.04 (release 20201211.
On Tue, Jan 05, 2021 at 15:12:55 +0100, Peter Krempa wrote:
> On Mon, Jan 04, 2021 at 15:30:19 -0500, Masayoshi Mizuma wrote:
> > On Sat, Dec 19, 2020 at 11:30:39PM -0500, Masayoshi Mizuma wrote:
[...]
> {"execute":"cont"}
>
> So that is a no-go. Some disk bus-es such as IDE don't support
27 matches
Mail list logo
