the connection.
Fix it by turning every negative return from qio_channel_read_all into
-EIO returned from nbd_read. Apparently that was the original behavior,
but got broken later. Also adjust nbd_readXX to follow.
Fixes: e6798f06a6 ("nbd: generalize usage of nbd_read")
Signed-off-by: R
0 in ?? ()
Fix it by checking that the connection coroutine is non-null before
trying to enter it. If it is null, no entering is needed, as the
connection is probably going down anyway.
Signed-off-by: Roman Kagan
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block/nbd.c | 16 +---
1 fil
it by checking that the iochannel is non-null before trying to
detach it from the aio_context. If it is null, no detaching is needed,
and it will get reattached in the proper aio_context once the connection
is reestablished.
Signed-off-by: Roman Kagan
Reviewed-by: Vladimir Sementsov-Ogievskiy
---
block
ed backtraces in log messages
- add r-b by Vladimir
Roman Kagan (3):
block/nbd: only detach existing iochannel from aio_context
block/nbd: only enter connection coroutine if it's present
nbd: make nbd_read* return -EIO on error
include/block/nbd.h | 7 ---
block/nbd.c
On Fri, Jan 29, 2021 at 08:51:39AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 28.01.2021 23:14, Roman Kagan wrote:
> > During the final phase of migration the NBD reconnection logic may
> > encounter situations it doesn't expect during regular operation.
> >
> >
On Fri, Jan 29, 2021 at 08:37:13AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 28.01.2021 23:14, Roman Kagan wrote:
> > When the reconnect in NBD client is in progress, the iochannel used for
> > NBD connection doesn't exist. Therefore an attempt to detach it from
>
to
detach it from the aio_context. If it is null, no detaching is needed,
and it will get reattached in the proper aio_context once the connection
is reestablished.
Signed-off-by: Roman Kagan
---
block/nbd.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/block/nbd.c b/bl
the connection.
Fix it by turning every negative return from qio_channel_read_all into
-EIO returned from nbd_read. Apparently that was the original behavior,
but got broken later. Also adjust nbd_readXX to follow.
Fixes: e6798f06a6 ("nbd: generalize usage of nbd_read")
Signed-off-by: R
delay" runs a stress load (fio with big queue depth)
in the guest on that drive and is migrated (e.g. to a file), while the
nbd server is SIGKILL-ed and restarted every second.
See the individual patches for specific crash conditions and more
detailed explanations.
Roman Kagan (3):
block/nbd: o
lib/x86_64-linux-gnu/libpthread.so.0
Fix it by checking that the connection coroutine is non-null before
trying to enter it. If it is null, no entering is needed, as the
connection is probably going down anyway.
Signed-off-by: Roman Kagan
---
block/nbd.c | 16 +---
1 file changed
On Mon, Dec 14, 2020 at 01:40:45PM +0300, Roman Kagan wrote:
> On Mon, Nov 23, 2020 at 10:47:32AM +0300, Roman Kagan wrote:
> > On Mon, Nov 02, 2020 at 08:37:50AM +0300, Roman Kagan wrote:
> > > When the slot is in steady powered-off state and the device is being
> > &g
On Mon, Nov 23, 2020 at 10:47:32AM +0300, Roman Kagan wrote:
> On Mon, Nov 02, 2020 at 08:37:50AM +0300, Roman Kagan wrote:
> > When the slot is in steady powered-off state and the device is being
> > removed, there's no need to press the attention button. Nor is it
> > man
On Mon, Nov 02, 2020 at 08:37:50AM +0300, Roman Kagan wrote:
> When the slot is in steady powered-off state and the device is being
> removed, there's no need to press the attention button. Nor is it
> mandated by the Standard Hot-Plug Controller Specification, Rev. 1.0.
>
> Moreo
On Thu, Oct 22, 2020 at 02:40:26PM +0300, Marcel Apfelbaum wrote:
> From: Marcel Apfelbaum
>
> During PCIe Root Port's transition from Power-Off to Power-ON (or vice-versa)
> the "Slot Control Register" has the "Power Indicator Control"
> set to "Blinking" expressing a "power transition" mode.
>
is in powered-off state and is being ejected.
FWIW pcie implementation doesn't suffer from this problem.
Signed-off-by: Roman Kagan
---
hw/pci/shpc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/pci/shpc.c b/hw/pci/shpc.c
index b00dce629c..837159c5bd 100644
--- a/hw/pci/shpc.c
On Sun, Oct 04, 2020 at 08:04:42PM +0200, Philippe Mathieu-Daudé wrote:
> There is a number of contributors from this domain,
> add its own entry to the gitdm domain map.
>
> Cc: Alexey Kirillov
> Cc: Alexey Krasikov
> Cc: Anton Kuchin
> Cc: Dima Stepanov
> Cc: Evge
On Fri, May 29, 2020 at 01:55:08AM +0300, Roman Kagan wrote:
> BlockConf includes several properties counted in bytes.
>
> Enhance their handling in some aspects, specifically
>
> - accept common size suffixes (k, m)
> - perform consistency checks on the values
> -
On Fri, May 29, 2020 at 11:53:26AM +0200, Markus Armbruster wrote:
> Roman Kagan writes:
>
> > Several block device properties related to blocksize configuration must
> > be in certain relationship WRT each other: physical block must be no
> > smaller than logical block;
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessarily tight, and we've seen bigger block sizes
handy at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
and virtio-blk
devices as an uint16_t in units of logical blocks, introduce an
additional check in blkconf_blocksizes to prevent its silent truncation.
Signed-off-by: Roman Kagan
---
v7 -> v8:
- replace stringify with %u in the error message [Eric]
- fix wording in the log [Eric]
include
Add getter for size32, and use it for blocksize, too.
In its human-readable branch, it reports approximate size in
human-readable units next to the exact byte value, like the getter for
64bit size does.
Adjust the expected test output accordingly.
Signed-off-by: Roman Kagan
Reviewed-by: Eric
property type in a followup commit).
The getter for size32 is left out for a separate patch as its benefit is
less obvious, and it affects test output; for now the regular uint32
getter is used.
Signed-off-by: Roman Kagan
---
v7 -> v8:
- replace stringify with %u in the error message [Eric]
-
It appears convenient to be able to specify physical_block_size and
logical_block_size using common size suffixes.
Teach the blocksize property setter to interpret them. Also express the
upper and lower limits in the respective units.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Blake
---
hw
, add corresponding consistency
checks to blkconf_blocksizes, adjusting its signature to communicate
possible error to the caller. Also remove the now redundant consistency
checks from the specific devices.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Blake
Reviewed-by: Paul Durrant
---
include
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Blake
---
hw/core/qdev-properties.c | 21 +++--
1 file
e limit in the log and comment [Eric]
v1 -> v2:
- cap the property at 2 MiB [Eric]
- accept size suffixes
Roman Kagan (8):
virtio-blk: store opt_io_size with correct size
block: consolidate blocksize properties consistency checks
qdev-properties: blocksize: use same limits in code a
On Thu, May 28, 2020 at 04:45:19PM -0500, Eric Blake wrote:
> On 5/28/20 4:39 PM, Roman Kagan wrote:
> > Introduce size32 property type which handles size suffixes (k, m) just
> > like size property, but is uint32_t rather than uint64_t.
>
> Does it handle 'g' as well?
Add getter for size32, and use it for blocksize, too.
In its human-readable branch, it reports approximate size in
human-readable units next to the exact byte value, like the getter for
64bit size does.
Adjust the expected test output accordingly.
Signed-off-by: Roman Kagan
---
v6 ->
by scsi and virtio-blk
devices as an uint16_t in units of logical blocks, introduce an
additional check in blkconf_blocksizes to prevent its silent truncation.
Signed-off-by: Roman Kagan
---
v6 -> v7:
- split out into separate patch [Eric]
- avoid overflow in min_io_size check [Eric]
include
It appears convenient to be able to specify physical_block_size and
logical_block_size using common size suffixes.
Teach the blocksize property setter to interpret them. Also express the
upper and lower limits in the respective units.
Signed-off-by: Roman Kagan
---
v6 -> v7:
- split
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Blake
---
v4 -> v5:
- split out into separate patch [Philippe]
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessarily tight, and we've seen bigger block sizes
handy at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
cept size suffixes
Roman Kagan (8):
virtio-blk: store opt_io_size with correct size
block: consolidate blocksize properties consistency checks
qdev-properties: blocksize: use same limits in code and description
qdev-properties: add size32 property type
qdev-properties: make blocksize accept siz
, add corresponding consistency
checks to blkconf_blocksizes, adjusting its signature to communicate
possible error to the caller. Also remove the now redundant consistency
checks from the specific devices.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Blake
Reviewed-by: Paul Durrant
---
v5 ->
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
property type in a followup commit).
The getter for size32 is left out for a separate patch as its benefit is
less obvious, and it affects test output; for now the regular uint32
getter is used.
Signed-off-by: Roman Kagan
---
v6 -> v7:
- split out into separate patch [Eric]
include/hw/q
On Wed, May 27, 2020 at 09:50:39AM -0500, Eric Blake wrote:
> On 5/27/20 7:45 AM, Roman Kagan wrote:
> > Several BlockConf properties represent respective sizes in bytes so it
> > makes sense to accept size suffixes for them.
> >
> > Turn them all into uint32_t and use
, add corresponding consistency
checks to blkconf_blocksizes, adjusting its signature to communicate
possible error to the caller. Also remove the now redundant consistency
checks from the specific devices.
Signed-off-by: Roman Kagan
---
v5 -> v6:
- fix forgotten xen-block and swim
v4 -> v5:
.
Signed-off-by: Roman Kagan
---
v5 -> v6:
- add prop_size32 instead of going with 64bit
v4 -> v5:
- make all BlockConf size props support suffixes
- move qdev_prop_blocksize after qdev_prop_size, to reuse get_size
- reword error messages [Kevin]
include/hw/block/block.h | 12 +-
include/h
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
]
- check min_io_size against truncation [Kevin]
v2 -> v3:
- mention qcow2 cluster size limit in the log and comment [Eric]
v1 -> v2:
- cap the property at 2 MiB [Eric]
- accept size suffixes
Roman Kagan (5):
virtio-blk: store opt_io_size with correct size
block: consolidate blocksize propert
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
---
v4 -> v5:
- split out into separate patch [Philippe]
hw/core/qdev-properties.c |
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessary tight, and we've seen bigger block sizes handy
at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
Please ignore the series, I forgot xen-block device.
Roman.
On Tue, May 26, 2020 at 11:17:35AM +0300, Roman Kagan wrote:
> BlockConf includes several properties counted in bytes.
>
> Enhance their handling in a some aspects, specifically
>
> - accept common size suffixes (k,
of a specific width (uint16_t for min_io_size and
uint32_t for opt_io_size and discard_granularity) in units of logical
blocks, introduce extra checks in blkconf_blocksizes to prevent their
silent truncation.
Signed-off-by: Roman Kagan
---
v4 -> v5:
- make all BlockConf size props support suffixes
- m
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
---
v4 -> v5:
- split out into separate patch [Philippe]
hw/core/qdev-properties.c |
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessary tight, and we've seen bigger block sizes handy
at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
, add corresponding consistency
checks to blkconf_blocksizes, adjusting its signature to communicate
possible error to the caller. Also remove the now redundant consistency
checks from the specific devices.
Signed-off-by: Roman Kagan
---
v4 -> v5:
- fix/reword error messages [Philippe, Kevin]
-
-> v3:
- mention qcow2 cluster size limit in the log and comment [Eric]
v1 -> v2:
- cap the property at 2 MiB [Eric]
- accept size suffixes
Roman Kagan (5):
virtio-blk: store opt_io_size with correct size
block: consolidate blocksize properties consistency checks
qdev-properties: blocksi
On Wed, May 20, 2020 at 05:54:44PM +0200, Kevin Wolf wrote:
> Am 20.05.2020 um 10:06 hat Roman Kagan geschrieben:
> > Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> > 32-bit for logical_block_size, physical_block_size, and min_io_size.
> > Ho
On Wed, May 20, 2020 at 11:04:44AM +0200, Philippe Mathieu-Daudé wrote:
> On 5/20/20 10:06 AM, Roman Kagan wrote:
> > Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> > 32-bit for logical_block_size, physical_block_size, and min_io_size.
> > Ho
On Wed, May 20, 2020 at 10:57:00AM +0200, Philippe Mathieu-Daudé wrote:
> On 5/20/20 10:06 AM, Roman Kagan wrote:
> > Several block device properties related to blocksize configuration must
> > be in certain relationship WRT each other: physical block must be no
> > small
On Wed, May 20, 2020 at 06:44:44AM -0400, Michael S. Tsirkin wrote:
> On Wed, May 20, 2020 at 11:06:55AM +0300, Roman Kagan wrote:
> > The width of opt_io_size in virtio_blk_topology is 32bit.
> >
> > Use the appropriate accessor to store it.
> >
> > Signed-of
On Wed, May 20, 2020 at 05:36:58PM +0200, Kevin Wolf wrote:
> Am 20.05.2020 um 10:06 hat Roman Kagan geschrieben:
> > The width of opt_io_size in virtio_blk_topology is 32bit.
>
> I think you mean virtio_blk_config?
I consulted virtio-v1.1 spec where the topology-related fie
, add corresponding consistency
checks to blkconf_blocksizes, adjusting its signature to communicate
possible error to the caller. Also remove the now redundant consistency
checks from the specific devices.
Signed-off-by: Roman Kagan
---
v4: new patch
include/hw/block/block.h | 2 +-
hw/block
suffixes
Roman Kagan (3):
virtio-blk: store opt_io_size with correct size
block: consolidate blocksize properties consistency checks
block: make BlockConf.*_size properties 32-bit
include/hw/block/block.h | 10 -
include/hw/qdev-properties.h | 2 +-
hw/block/block.c
as the devices which use min_io_size (virtio-blk and scsi) pass its
value to the guest in units of logical blocks in a 16bit field, to
prevent its silent truncation add a corresponding check to
blkconf_blocksizes.
Signed-off-by: Roman Kagan
---
v3 -> v4:
- check min_io_size against truncation [Kevin]
The width of opt_io_size in virtio_blk_topology is 32bit.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
---
v4: new patch
hw/block/virtio-blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index
On Tue, May 19, 2020 at 04:08:26PM +0200, Kevin Wolf wrote:
> Am 29.04.2020 um 11:18 hat Roman Kagan geschrieben:
> > Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> > 32-bit for logical_block_size, physical_block_size, and min_io_size.
> > Ho
On Wed, Apr 29, 2020 at 12:18:13PM +0300, Roman Kagan wrote:
> Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> 32-bit for logical_block_size, physical_block_size, and min_io_size.
> However, the properties in BlockConf are defined as uint16_t limiting
> the val
the VMBus entry to.
Thanks,
Roman.
> Thanks,
> -- Jon.
>
> > On Mon, 11 May 2020 23:11:23 +0300
> > Roman Kagan wrote:
> >
> > > On Thu, May 07, 2020 at 06:14:25AM +0300, Jon Doron wrote:
> > > > Igor it seems like the IRQ being used is 5 and no
On Thu, Apr 09, 2020 at 06:35:18AM +0300, Jon Doron wrote:
> On 08/04/2020, Roman Kagan wrote:
> > On Wed, Apr 08, 2020 at 07:16:39AM +0300, Jon Doron wrote:
> > > Well I have implemented the hyperv synthetic kernel debugger interface,
> > > but
> > > on Wind
On Thu, May 07, 2020 at 06:14:25AM +0300, Jon Doron wrote:
> Igor it seems like the IRQ being used is 5 and not 7 & 13 like in the
> current patch.
HyperV using irq 5 doesn't mean QEMU has to too. Especially so as no
guest was noticed to use the irqs in ACPI. I'd rather try and test if
the
However, since no guest actually used
those irqs, it appeared not worth the effort. Dunno what problems can
arise from the conflicts.
> > Signed-off-by: Evgeny Yakovlev
> > Signed-off-by: Roman Kagan
> > Signed-off-by: Maciej S. Szmigiero
> > Signed-off-by: Jon
On Wed, Apr 29, 2020 at 02:59:31PM +0200, Philippe Mathieu-Daudé wrote:
> On 4/29/20 2:19 PM, Roman Kagan wrote:
> > On Wed, Apr 29, 2020 at 11:41:04AM +0200, Philippe Mathieu-Daudé wrote:
> > > Cc'ing virtio-blk and scsi maintainers.
> > >
> > > On
On Wed, Apr 29, 2020 at 11:41:04AM +0200, Philippe Mathieu-Daudé wrote:
> Cc'ing virtio-blk and scsi maintainers.
>
> On 4/29/20 11:18 AM, Roman Kagan wrote:
> > Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> > 32-bit for logical_block_size
-by: Roman Kagan
Reviewed-by: Eric Blake
---
v2 -> v3:
- mention qcow2 cluster size limit in the log and comment [Eric]
v1 -> v2:
- cap the property at 2 MiB [Eric]
- accept size suffixes
include/hw/block/block.h | 8
include/hw/qdev-properties.h | 2 +-
hw/core/qdev-proper
On Wed, Apr 08, 2020 at 07:16:39AM +0300, Jon Doron wrote:
> On 07/04/2020, Maciej S. Szmigiero wrote:
> > On 07.04.2020 20:56, Roman Kagan wrote:
> > > On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote:
> > > > Well I want it to be merged in :-)
> >
On Tue, Apr 07, 2020 at 09:03:05PM +0200, Maciej S. Szmigiero wrote:
> On 07.04.2020 20:56, Roman Kagan wrote:
> > On Mon, Apr 06, 2020 at 11:20:39AM +0300, Jon Doron wrote:
> >> Well I want it to be merged in :-)
> >
> > Hmm I'm curious why, it has little to offe
eed for
improvement, too, but should be testable at least.
Thanks,
Roman.
> On Mon, Apr 6, 2020, 10:32 Roman Kagan wrote:
>
> > On Fri, Apr 03, 2020 at 11:00:27PM +0200, Maciej S. Szmigiero wrote:
> > > It seems to me that Roman might not be getting our e-mails since his
> &
, Jon Doron wrote:
> >>>>> Guest OS uses ACPI to discover vmbus presence. Add a corresponding
> >>>>> entry to DSDT in case vmbus has been enabled.
> >>>>>
> >>>>> Experimentally Windows guests were found to require this entry to
handy
at times.
Make them 32 bit instead and lift the limitation up to 2 MiB which
appears to be good enough for everybody.
As the values can now be fairly big and awkward to type, make the
property setter accept common size suffixes (k, m).
Signed-off-by: Roman Kagan
---
v1 -> v2:
-
On Mon, Mar 02, 2020 at 01:55:02PM +0300, Roman Kagan wrote:
> On Thu, Feb 13, 2020 at 04:55:44PM +0300, Roman Kagan wrote:
> > On Thu, Feb 13, 2020 at 06:47:10AM -0600, Eric Blake wrote:
> > > On 2/13/20 2:01 AM, Roman Kagan wrote:
> > > > On Wed, Feb 12, 2020 a
On Thu, Feb 13, 2020 at 04:55:44PM +0300, Roman Kagan wrote:
> On Thu, Feb 13, 2020 at 06:47:10AM -0600, Eric Blake wrote:
> > On 2/13/20 2:01 AM, Roman Kagan wrote:
> > > On Wed, Feb 12, 2020 at 03:44:19PM -0600, Eric Blake wrote:
> > > > On 2/11/20 5:54 AM, Roman
On Thu, Feb 13, 2020 at 06:47:10AM -0600, Eric Blake wrote:
> On 2/13/20 2:01 AM, Roman Kagan wrote:
> > On Wed, Feb 12, 2020 at 03:44:19PM -0600, Eric Blake wrote:
> > > On 2/11/20 5:54 AM, Roman Kagan wrote:
> > > > Devices (virtio-blk, scsi, etc.) and the block lay
On Wed, Feb 12, 2020 at 03:44:19PM -0600, Eric Blake wrote:
> On 2/11/20 5:54 AM, Roman Kagan wrote:
> > Devices (virtio-blk, scsi, etc.) and the block layer are happy to use
> > 32-bit for logical_block_size, physical_block_size, and min_io_size.
> > However, the pr
handy
at times.
Make them 32 bit instead and lift the limitation.
Signed-off-by: Roman Kagan
---
hw/core/qdev-properties.c| 21 -
include/hw/block/block.h | 8
include/hw/qdev-properties.h | 2 +-
3 files changed, 17 insertions(+), 14 deletions(-)
diff
On Mon, Jan 13, 2020 at 05:36:44PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Hyperv's synic (that we emulate) is a feature that allows the guest
> to place some magic (4k) pages of RAM anywhere it likes in GPA.
> This confuses vhost's RAM section merging
On Thu, Jan 09, 2020 at 04:27:45PM +, Dr. David Alan Gilbert wrote:
> * Roman Kagan (rka...@virtuozzo.com) wrote:
> > On Thu, Jan 09, 2020 at 01:28:21PM +, Dr. David Alan Gilbert wrote:
> > > * Roman Kagan (rka...@virtuozzo.com) wrote:
> > > > On Thu, Ja
On Thu, Jan 09, 2020 at 01:28:21PM +, Dr. David Alan Gilbert wrote:
> * Roman Kagan (rka...@virtuozzo.com) wrote:
> > On Thu, Jan 09, 2020 at 02:00:00PM +0100, Vitaly Kuznetsov wrote:
> > > "Dr. David Alan Gilbert" writes:
> > >
> > > > And
On Thu, Jan 09, 2020 at 02:00:00PM +0100, Vitaly Kuznetsov wrote:
> "Dr. David Alan Gilbert" writes:
>
> > And I think vhost-user will fail if you have too many sections - and
> > the 16 sections from synic I think will blow the slots available.
> >
>
> SynIC is percpu, it will allocate two 4k
On Wed, Jan 08, 2020 at 01:53:53PM +, Dr. David Alan Gilbert (git) wrote:
> Mark the synic pages as ram_device so that they won't be visible
> to vhost.
Unless I'm misreading the code this also makes them invisible to
migration.
I need some more reading on the ram_device region behavior to
On Wed, Jan 08, 2020 at 01:53:52PM +, Dr. David Alan Gilbert (git) wrote:
> Don't pass RAM blocks that are marked as ram devices to vhost.
> There's normally something special about them and they're not
> normally just shared memory.
Does this something special about them, whatever it is,
On Wed, Jan 08, 2020 at 01:53:51PM +, Dr. David Alan Gilbert (git) wrote:
> Hyperv's synic (that we emulate) is a feature that allows the guest
> to place some magic (4k) pages of RAM anywhere it likes in GPA.
> This confuses vhost's RAM section merging when these pages
> land over the top of
slight preference towards using WITH_RCU_READ_LOCK_GUARD
instead of sticking RCU_READ_LOCK_GUARD in the middle of the function
and implicitly relying on there being none but trivial statements past
the rcu-protected section.
Nothing that I would insist on, though, so
Reviewed-by: Roman Kagan
On Wed, Nov 13, 2019 at 10:29:00AM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
> > On Tue, Nov 12, 2019 at 11:34:27AM +0800, lantianyu1...@gmail.com wrote:
> >> From: Tianyu Lan
> >>
> >> Hyper-V direct tlb flush targets KVM on Hyper-V guest.
> &g
+"Hyper-V %s requires KVM hypervisor signature "
> +"to be hidden (-kvm).\n",
> +kvm_hyperv_properties[HYPERV_FEAT_DIRECT_TLBFLUSH].desc);
> +return -ENOSYS;
> +}
In view of my comment above, this "else if" clause may become
unnecessary.
However, it doesn't hurt either, and doesn't make things worse, so, if
this is seen as 4.2 material and the general KVM vs Hyper-V hypercall
conflict resolution is postponed till after 4.2, the patch looks ok as
it is.
Under this provision
Reviewed-by: Roman Kagan
> +}
> +
> if (cpu->hyperv_passthrough) {
> /* We already copied all feature words from KVM as is */
> r = cpuid->nent;
> --
> 2.14.5
>
On Mon, Nov 11, 2019 at 12:18:48PM +0300, Andrey Shinkevich wrote:
>
>
> On 08/11/2019 17:05, Roman Kagan wrote:
> > On Fri, Nov 08, 2019 at 01:49:50PM +, Vladimir Sementsov-Ogievskiy
> > wrote:
> >> 01.11.2019 19:54, Andrey Shinkevich wrote:
> >&g
On Fri, Nov 08, 2019 at 01:49:50PM +, Vladimir Sementsov-Ogievskiy wrote:
> 01.11.2019 19:54, Andrey Shinkevich wrote:
> > +def check_proc_NBD(proc, connector):
> > +try:
> > +exitcode = proc.wait(timeout=10)
> > +
> > +if exitcode < 0:
> > +log('NBD {}: EXIT
On Fri, Oct 25, 2019 at 02:19:19PM +0200, Jens Freimann wrote:
> This is implementing the host side of the net_failover concept
> (https://www.kernel.org/doc/html/latest/networking/net_failover.html)
>
> Changes since v5:
> * rename net_failover_pair_id parameter/property to failover_pair_id
> *
On Tue, Oct 22, 2019 at 07:04:11PM +0200, Paolo Bonzini wrote:
> On 16/10/19 15:07, lantianyu1...@gmail.com wrote:
Somehow this patch never got through to me so I'll reply here.
> > From: Tianyu Lan
> >
> > Hyper-V direct tlb flush targets KVM on Hyper-V guest.
> > Enable direct TLB flush for
On Wed, Oct 02, 2019 at 05:22:43PM +0300, Andrey Shinkevich wrote:
> Added possibility to write compressed data by using the
> blk_write_compressed. This action has the limitations of the format
> driver. For example we can't write compressed data over other.
>
> $ ./qemu-img create -f qcow2 -o
On Tue, Oct 01, 2019 at 06:52:52PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
> can't see
On Fri, Jun 21, 2019 at 12:49:07PM +, Roman Kagan wrote:
> On Thu, Jun 06, 2019 at 01:22:33PM +0000, Roman Kagan wrote:
> > On Mon, May 27, 2019 at 11:05:38AM +0000, Roman Kagan wrote:
> > > On Thu, May 23, 2019 at 12:31:16PM +0100, Alex Bennée wrote:
> > > >
gh the rest of the patch introduces a
> feature checking mechanism. So I've fixed the KVM_EXIT_HYPERV_SYNIC in
> hyperv-stub to do the same feature check as in the real hyperv.c
>
> Signed-off-by: Alex Bennée
> Cc: Vitaly Kuznetsov
> Cc: Paolo Bonzini
> Cc: Roman Kagan
> -
On Mon, Jun 24, 2019 at 11:58:23AM +0100, Alex Bennée wrote:
> Roman Kagan writes:
>
> > It was introduced in commit b129972c8b41e15b0521895a46fd9c752b68a5e,
> > with the following motivation:
>
> I can't find this commit in my tree.
On Thu, Jun 06, 2019 at 01:22:33PM +, Roman Kagan wrote:
> On Mon, May 27, 2019 at 11:05:38AM +0000, Roman Kagan wrote:
> > On Thu, May 23, 2019 at 12:31:16PM +0100, Alex Bennée wrote:
> > >
> > > Roman Kagan writes:
> > >
> > >
On Tue, Jun 18, 2019 at 10:35:05AM +, Roman Kagan wrote:
> On Tue, Jun 18, 2019 at 11:24:57AM +1000, Vadim Rozenfeld wrote:
> > On Mon, 2019-06-17 at 14:49 -0300, Eduardo Habkost wrote:
> > > On Mon, Jun 17, 2019 at 05:32:13PM +, Roman Kagan wrote:
> > > >
101 - 200 of 673 matches
Mail list logo
