ted valid user
> cases. As a compromise, allow any card size, but warn only power of 2
> sizes are supported, still suggesting the user how to increase a
> card with 'qemu-img resize'.
>
> Cc: Tom Yan
> Cc: Warner Losh
> Buglink: https://bugs.launchpad.net/qemu/+bug/1910586
> Signed-
On Wed, 9 Dec 2020 at 21:54, 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.
&g
5 Nov 2020 at 01:32, 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.
>
>
.com/qemu/qemu/blob/v5.1.0/block/file-posix.c#L3504
On Mon, 7 Sep 2020 at 03:50, Dmitry Fomichev wrote:
>
>
>
> > -Original Message-
> > From: Qemu-block > bounces+dmitry.fomichev=wdc@nongnu.org> On Behalf Of Maxim
> > Levitsky
> > Sent: Sunday,
inal issue, if desired.
On Sun, 6 Sep 2020 at 20:53, Maxim Levitsky wrote:
>
> On Sun, 2020-09-06 at 19:04 +0800, Tom Yan wrote:
> > Maybe you want to add some condition for this:
> > https://github.com/qemu/qemu/blob/v5.1.0/nbd/server.c#L659
> > Or not clamp it at all.
> &
Maybe you want to add some condition for this:
https://github.com/qemu/qemu/blob/v5.1.0/nbd/server.c#L659
Or not clamp it at all.
On Sun, 6 Sep 2020 at 18:58, Tom Yan wrote:
>
> In commit 867eccfed84f96b54f4a432c510a02c2ce03b430, Levitsky appears
> to have assumed that the only "SC
mark" `-device scsi-block` as sg either. It
will probably bring even more unexpected problems, because they are
literally different sets of things behind the scene / in the kernel.
On Fri, 4 Sep 2020 at 10:09, Tom Yan wrote:
>
> sg devices have different major/minor than their corres
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 max segments.
Signed-off-by: Tom Yan
---
block/file
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
---
v2: fix get_max_transfer_length for non-sg devices; also add/fix
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
---
v2: fix get_max_transfer_length for non-sg devices; also add/fix
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
---
v2: fix get_max_transfer_length for non-sg devices; also add/fix
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 max segments.
Signed-off-by: Tom Yan
---
block/file
12 matches
Mail list logo