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 :-)
> >
initially. 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-o
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 guest
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
tick 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 a
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
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.
> > Howev
s 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 [Ke
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
size 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
, 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
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 fields
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 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 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.
> > Howev
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.
> > Howev
-> 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
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
, 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]
-
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
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 |
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
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,
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
]
- 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
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
, 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:
ation.
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 +-
incl
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
s new 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
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
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 ->
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
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 out i
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
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 ->
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' a
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
, 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
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
s new 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 [Eri
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 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
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
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
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;
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 h
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, make
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 be
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 p
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 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 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 when
On Fri, Mar 29, 2019 at 03:18:25PM +0100, Vitaly Kuznetsov wrote:
> KVM now supports reporting supported Hyper-V features through CPUID
> (KVM_GET_SUPPORTED_HV_CPUID ioctl). Going forward, this is going to be
> the only way to announce new functionality and this has already happened
> with Direct M
On Fri, Mar 29, 2019 at 03:18:27PM +0100, Vitaly Kuznetsov wrote:
> Currently, there is no doc describing hv-* CPU flags, people are
> encouraged to get the information from Microsoft Hyper-V Top Level
> Functional specification (TLFS). There is, however, a bit of QEMU
> specifics.
This is appreci
On Fri, Mar 29, 2019 at 03:18:28PM +0100, Vitaly Kuznetsov wrote:
> In many case we just want to give Windows guests all currently supported
> Hyper-V enlightenments and that's where this new mode may come handy. We
> pass through what was returned by KVM_GET_SUPPORTED_HV_CPUID.
The only one out o
On Thu, May 23, 2019 at 12:31:16PM +0100, Alex Bennée wrote:
>
> Roman Kagan writes:
>
> > I came across the following AB-BA deadlock:
> >
> > vCPU thread main thread
> > --- -
On Fri, May 17, 2019 at 04:19:16PM +0200, Vitaly Kuznetsov wrote:
> Representing Hyper-V properties as bits will allow us to check features
> and dependencies between them in a natural way.
>
> Suggested-by: Roman Kagan
> Signed-off-by: Vitaly Kuznetsov
> ---
> hw/i3
On Fri, May 17, 2019 at 04:19:17PM +0200, Vitaly Kuznetsov wrote:
> KVM now supports reporting supported Hyper-V features through CPUID
> (KVM_GET_SUPPORTED_HV_CPUID ioctl). Going forward, this is going to be
> the only way to announce new functionality and this has already happened
> with Direct M
On Mon, May 27, 2019 at 06:39:53PM +0200, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
> > On Fri, May 17, 2019 at 04:19:17PM +0200, Vitaly Kuznetsov wrote:
> >> +static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max)
> >> +{
> >> +struct kvm_
-exclusive sections against BQL, so I thought I would try to
address that. This patchset is my feeble attempt at this; I'm not sure
I fully comprehend all the consequences (rather, I'm sure I don't) hence
RFC.
Roman Kagan (2):
cpus-common: nuke finish_safe_work
cpus-common: asse
() cpu_list_add()
async_synic_update()finish_safe_work()
qemu_mutex_lock_iothread() cpu_exec_start()
So remove it. This paves the way to establishing a strict nesting rule
of never entering the exclusive section with the BQL taken.
Signed-off-by: Roman
Assert that the cpu-exclusive sections are never entered/left with the
BQL taken.
Signed-off-by: Roman Kagan
---
cpus-common.c | 4
1 file changed, 4 insertions(+)
diff --git a/cpus-common.c b/cpus-common.c
index 023cfebfa3..9aa75fe1ba 100644
--- a/cpus-common.c
+++ b/cpus-common.c
On Fri, Jan 25, 2019 at 12:41:51PM +0100, Vitaly Kuznetsov wrote:
> In many case we just want to give Windows guests all currently supported
> Hyper-V enlightenments and that's where this new mode may come handy. We
> pass through what was returned by KVM_GET_SUPPORTED_HV_CPUID.
How is the compati
On Fri, Jan 25, 2019 at 02:46:42PM +0100, Vitaly Kuznetsov wrote:
> Roman Kagan writes:
>
> > On Fri, Jan 25, 2019 at 12:41:51PM +0100, Vitaly Kuznetsov wrote:
> >> In many case we just want to give Windows guests all currently supported
> >> Hyper-V enlightenments
slot 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
---
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 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.
>
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
> - li
601 - 673 of 673 matches
Mail list logo
