Hi,
This series has been reviewed by Alberto, can someone review / merge this?
On 6/27/23 15:24, zhenwei pi wrote:
v1 -> v2:
- rename 'ThrottleTimerType' to 'ThrottleType'
- add assertion to throttle_schedule_timer
Something remained:
- 'bool is_write' is no longer appropriate, the related
From: Akihiko Odaki
Currently the only implementers of ARI is SR-IOV devices, and they
behave similar. Share the ARI next function number.
Signed-off-by: Akihiko Odaki
Reviewed-by: Ani Sinha
Message-Id: <20230710153838.33917-2-akihiko.od...@daynix.com>
Reviewed-by: Michael S. Tsirkin
On 31/5/23 23:10, Bernhard Beschow wrote:
This series is split off from a more general PCI IDE refactoring aiming for a
common implementation of the PCI IDE controller specification for all
TYPE_PCI_IDE models [1].
Bernhard Beschow (7):
hw/ide/pci: Expose legacy interrupts as named GPIOs
On 10/7/23 17:35, Alex Bennée wrote:
Signed-off-by: Alex Bennée
---
include/hw/virtio/virtio.h | 6 ++
1 file changed, 6 insertions(+)
Reviewed-by: Philippe Mathieu-Daudé
On 10/7/23 17:35, Alex Bennée wrote:
Fixes: 544f0278af (virtio: introduce macro VIRTIO_CONFIG_IRQ_IDX)
Signed-off-by: Alex Bennée
---
hw/display/vhost-user-gpu.c| 4 ++--
hw/net/virtio-net.c| 4 ++--
hw/virtio/vhost-user-fs.c | 4 ++--
hw/virtio/vhost-user-gpio.c|
Am 31. Mai 2023 21:10:36 UTC schrieb Bernhard Beschow :
>This series is split off from a more general PCI IDE refactoring aiming for a
>
>common implementation of the PCI IDE controller specification for all
>
>TYPE_PCI_IDE models [1].
>
>
>
>The first three patches resolve a circular
> +static const TypeInfo vud_info = {
> +.name = TYPE_VHOST_USER_DEVICE,
> +.parent = TYPE_VHOST_USER_BASE,
> +.instance_size = sizeof(VHostUserBase),
> +.class_init = vud_class_init,
> +.class_size = sizeof(VHostUserBaseClass),
I wish you didn't tie the refactoring in with
On Mon, Jul 10, 2023 at 04:35:12PM +0100, Alex Bennée wrote:
> To use the generic device the user will need to provide the config
> region size via the command line. We also add a notifier so the guest
> can be pinged if the remote daemon updates the config.
>
> With these changes:
>
> -device
On Mon, Jun 26, 2023 at 07:08:34PM +0300, Andrey Drobyshev via wrote:
> Add testcase which checks that allocations during copy-on-read are
> performed on the subcluster basis when subclusters are enabled in target
> image.
>
> This testcase also triggers the following assert with previous commit
On Mon, Jun 26, 2023 at 07:08:33PM +0300, Andrey Drobyshev via wrote:
> When target image is using subclusters, and we align the request during
> copy-on-read, it makes sense to align to subcluster_size rather than
> cluster_size. Otherwise we end up with unnecessary allocations.
>
> This commit
On Mon, Jun 26, 2023 at 07:08:32PM +0300, Andrey Drobyshev via wrote:
> This is going to be used in the subsequent commit as requests alignment
> (in particular, during copy-on-read). This value only makes sense for
> the formats which support subclusters (currently QCOW2 only). If this
> field
Am 10. Juli 2023 10:16:35 UTC schrieb "Philippe Mathieu-Daudé"
:
>On 9/7/23 10:09, Bernhard Beschow wrote:
>> Since commit c0a55a0c9da2 "hw/sd/sdhci: Support big endian SD host controller
>> interfaces" sdhci_common_realize() forces all SD card controllers to use
>> either
>>
Hi, everyone,
I create a qcow2 image on a logical volume several mouths ago and attach
this image to my Qemu vm. It looks well at the beginning, but recently
there are some leaked clusters reported by `qemu-img check`. The easiest
way to repair these leaked clusters is run `qemu-img check -r
Make it clear the vhost-user-device is intended for expert use only.
Signed-off-by: Alex Bennée
---
v2
- make clear vhost-user-device for expert use
---
docs/system/devices/vhost-user-rng.rst | 2 ++
docs/system/devices/vhost-user.rst | 41 ++
2 files changed, 43
Now we can take advantage of the new base class and make
vhost-user-i2c a much simpler boilerplate wrapper. Also as this
doesn't require any target specific hacks we only need to build the
stubs once.
Signed-off-by: Alex Bennée
---
v2
- update to new inheritance scheme
- move build to
This will be useful if we end up having to consider initialising the
virtqs at a seperate time.
Signed-off-by: Alex Bennée
---
hw/virtio/vhost.c | 60 ---
1 file changed, 41 insertions(+), 19 deletions(-)
diff --git a/hw/virtio/vhost.c
Instead of requiring all the information up front allow the
vhost_dev_init to complete and then see what information we have from
the backend.
This does change the order around somewhat.
Signed-off-by: Alex Bennée
---
hw/virtio/vhost-user-device.c | 45 +--
1
Currently QEMU has to know some details about the back-end to be able
to setup the guest. While various parts of the setup can be delegated
to the backend (for example config handling) this is a very piecemeal
approach.
This patch suggests a new feature flag (VHOST_USER_PROTOCOL_F_STANDALONE)
The current implementers of ARI are all SR-IOV devices. The ARI next
function number field is undefined for VF according to PCI Express Base
Specification Revision 5.0 Version 1.0 section 9.3.7.7. The PF still
requires some defined value so end the linked list formed with the field
by specifying 0
Currently the only implementers of ARI is SR-IOV devices, and they
behave similar. Share the ARI next function number.
Signed-off-by: Akihiko Odaki
Reviewed-by: Ani Sinha
---
docs/pcie_sriov.txt | 4 ++--
include/hw/pci/pcie.h | 2 +-
hw/net/igb.c | 2 +-
hw/net/igbvf.c| 2
The ARI next function number field is undefined for VF. The PF should
end the linked list formed with the field by specifying 0.
Supersedes: <20230701070133.24877-1-akihiko.od...@daynix.com>
("[PATCH 0/4] pci: Compare function number and ARI next function number")
V6 -> V7:
s/old virt
I'm still not sure how I achieve by use case of the parent class
defining the following properties:
static Property vud_properties[] = {
DEFINE_PROP_CHR("chardev", VHostUserDevice, chardev),
DEFINE_PROP_UINT16("id", VHostUserDevice, id, 0),
DEFINE_PROP_UINT32("num_vqs",
Now we can take advantage of our new base class and make
vhost-user-rng a much simpler boilerplate wrapper. Also as this
doesn't require any target specific hacks we only need to build the
stubs once.
Signed-off-by: Alex Bennée
---
v2
- new derivation layout
- move directly to
In preparation for getting the details of the VirtIO device directly
from the vhost-user daemon we should connect once we have validated
the chardev. We will actually move the connection in the next patch to
keep the changes small and bisectable.
Signed-off-by: Alex Bennée
---
To use the generic device the user will need to provide the config
region size via the command line. We also add a notifier so the guest
can be pinged if the remote daemon updates the config.
With these changes:
-device vhost-user-device-pci,virtio-id=41,num_vqs=2,config_size=8
is equivalent
All the allocations are a function the number of vqs we are allocating
so let the vhost code deal with it directly. This allows to eliminate
some complexity of the clean-up code (because vhost_dev_init cleanups
after itself if it fails). We can also places where we store copies of
@vqs in child
These are useful functions for when you want proper inheritance of
functionality across realize/unrealize calls.
Signed-off-by: Alex Bennée
---
include/hw/qdev-core.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
Fixes: 544f0278af (virtio: introduce macro VIRTIO_CONFIG_IRQ_IDX)
Signed-off-by: Alex Bennée
---
hw/display/vhost-user-gpu.c| 4 ++--
hw/net/virtio-net.c| 4 ++--
hw/virtio/vhost-user-fs.c | 4 ++--
hw/virtio/vhost-user-gpio.c| 2 +-
hw/virtio/vhost-vsock-common.c | 4
Signed-off-by: Alex Bennée
---
include/hw/virtio/virtio.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 0492d26900..0671989383 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -276,6 +276,13 @@
Signed-off-by: Alex Bennée
---
include/hw/virtio/virtio.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 0671989383..631490bda4 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -219,6 +219,12 @@
Now the new base class supports config handling we can take advantage
and make vhost-user-gpio a much simpler boilerplate wrapper. Also as
this doesn't require any target specific hacks we only need to build
the stubs once.
Signed-off-by: Alex Bennée
---
v2
- use new vhost-user-base
- move
Lets document some more of the core VirtIODevice structure.
Signed-off-by: Alex Bennée
---
include/hw/virtio/virtio.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 631490bda4..c8f72850bc 100644
---
Now we have detected and validated the protocol support lets do the
probe. The empty state indicates no probe took place.
Signed-off-by: Alex Bennée
---
include/hw/virtio/vhost.h | 12 +++
hw/virtio/vhost-user.c| 73 +++
hw/virtio/vhost.c | 2
In theory we shouldn't need to repeat so much boilerplate to support
vhost-user backends. This provides a generic vhost-user-base QOM
object and a derived vhost-user-device for which the user needs to
provide the few bits of information that aren't currently provided by
the vhost-user protocol.
This is all pretty much boilerplate.
Signed-off-by: Alex Bennée
Tested-by: Erik Schilling
---
hw/virtio/vhost-user-device-pci.c | 71 +++
hw/virtio/meson.build | 1 +
2 files changed, 72 insertions(+)
create mode 100644
If the backend advertises F_STANDALONE validate that it supports the
other mandatory features or error out.
Signed-off-by: Alex Bennée
---
hw/virtio/vhost-user.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index
A lot of our vhost-user stubs are large chunks of boilerplate that do
(mostly) the same thing. This series attempts to fix that by defining
a new base class (vhost-user-base) which is used by a generic
vhost-user-device implementation. Then the rng, gpio and i2c
vhost-user devices become simple
On Jul 10 14:40, Kevin Wolf wrote:
> Am 10.07.2023 um 14:22 hat Klaus Jensen geschrieben:
> > On Jun 28 16:15, Kevin Wolf wrote:
> > > Now that bdrv_graph_wrlock() temporarily drops the AioContext lock that
> > > its caller holds, it can poll without causing deadlocks. We can now
> > > re-enable
Thank you, Stefan, I tested it with the extended set of tests and it addresses
the issue.
Regards,
Lukáš
Tested-by: Lukas Doktor
Dne 04. 07. 23 v 17:15 Stefan Hajnoczi napsal(a):
> The main loop thread can consume 100% CPU when using --device
> virtio-blk-pci,iothread=. ppoll() constantly
On Mon, Jul 10, 2023 at 12:16:35PM +0200, Philippe Mathieu-Daudé wrote:
> On 9/7/23 10:09, Bernhard Beschow wrote:
> > Since commit c0a55a0c9da2 "hw/sd/sdhci: Support big endian SD host
> > controller
> > interfaces" sdhci_common_realize() forces all SD card controllers to use
> > either
> >
Am 10.07.2023 um 14:22 hat Klaus Jensen geschrieben:
> On Jun 28 16:15, Kevin Wolf wrote:
> > Now that bdrv_graph_wrlock() temporarily drops the AioContext lock that
> > its caller holds, it can poll without causing deadlocks. We can now
> > re-enable graph locking.
> >
> > This reverts commit
On Jun 28 16:15, Kevin Wolf wrote:
> Now that bdrv_graph_wrlock() temporarily drops the AioContext lock that
> its caller holds, it can poll without causing deadlocks. We can now
> re-enable graph locking.
>
> This reverts commit ad128dff0bf4b6f971d05eb4335a627883a19c1d.
>
I'm seeing a pretty
On 09.06.23 10:33, Hanna Czenczek wrote:
bdrv_pad_request() relies on requests' lengths not to exceed SIZE_MAX,
which bdrv_check_qiov_request() does not guarantee.
bdrv_check_request32() however will guarantee this, and both of
bdrv_pad_request()'s callers (bdrv_co_preadv_part() and
On Mon, Jul 10, 2023 at 03:44:04PM +0530, Ani Sinha wrote:
>
>
> > On 10-Jul-2023, at 3:14 PM, Michael S. Tsirkin wrote:
> >
> > On Mon, Jul 10, 2023 at 02:49:55PM +0530, Ani Sinha wrote:
> >>
> >>
> >>> On 10-Jul-2023, at 2:46 PM, Michael S. Tsirkin wrote:
> >>>
> >>> On Mon, Jul 10, 2023
On Mon, 10 Jul 2023, Akihiko Odaki wrote:
> The current implementers of ARI are all SR-IOV devices. The ARI next
> function number field is undefined for VF according to PCI Express Base
> Specification Revision 5.0 Version 1.0 section 9.3.7.7. The PF still
> requires some defined value so end
> On 10-Jul-2023, at 1:38 PM, Akihiko Odaki wrote:
>
> Currently the only implementers of ARI is SR-IOV devices, and they
> behave similar. Share the ARI next function number.
>
> Signed-off-by: Akihiko Odaki
Reviewed-by: Ani Sinha
> ---
> docs/pcie_sriov.txt | 4 ++--
>
On 9/7/23 10:09, Bernhard Beschow wrote:
Since commit c0a55a0c9da2 "hw/sd/sdhci: Support big endian SD host controller
interfaces" sdhci_common_realize() forces all SD card controllers to use either
sdhci_mmio_le_ops or sdhci_mmio_be_ops, depending on the "endianness" property.
However, there
> On 10-Jul-2023, at 3:14 PM, Michael S. Tsirkin wrote:
>
> On Mon, Jul 10, 2023 at 02:49:55PM +0530, Ani Sinha wrote:
>>
>>
>>> On 10-Jul-2023, at 2:46 PM, Michael S. Tsirkin wrote:
>>>
>>> On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sinha wrote:
> On 05-Jul-2023, at
On Mon, Jul 10, 2023 at 02:49:55PM +0530, Ani Sinha wrote:
>
>
> > On 10-Jul-2023, at 2:46 PM, Michael S. Tsirkin wrote:
> >
> > On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sinha wrote:
> >>
> >>
> >>> On 05-Jul-2023, at 7:54 AM, Akihiko Odaki
> >>> wrote:
> >>>
> >>> The current
> On 10-Jul-2023, at 2:46 PM, Michael S. Tsirkin wrote:
>
> On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sinha wrote:
>>
>>
>>> On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote:
>>>
>>> The current implementers of ARI are all SR-IOV devices. The ARI next
>>> function number field is
On Mon, Jul 10, 2023 at 01:21:50PM +0530, Ani Sinha wrote:
>
>
> > On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote:
> >
> > The current implementers of ARI are all SR-IOV devices. The ARI next
> > function number field is undefined for VF according to PCI Express Base
> > Specification
The current implementers of ARI are all SR-IOV devices. The ARI next
function number field is undefined for VF according to PCI Express Base
Specification Revision 5.0 Version 1.0 section 9.3.7.7. The PF still
requires some defined value so end the linked list formed with the field
by specifying 0
The ARI next function number field is undefined for VF. The PF should
end the linked list formed with the field by specifying 0.
Supersedes: <20230701070133.24877-1-akihiko.od...@daynix.com>
("[PATCH 0/4] pci: Compare function number and ARI next function number")
V5 -> V6:
Clarify that the
Currently the only implementers of ARI is SR-IOV devices, and they
behave similar. Share the ARI next function number.
Signed-off-by: Akihiko Odaki
---
docs/pcie_sriov.txt | 4 ++--
include/hw/pci/pcie.h | 2 +-
hw/net/igb.c | 2 +-
hw/net/igbvf.c| 2 +-
hw/nvme/ctrl.c
> On 10-Jul-2023, at 1:23 PM, Akihiko Odaki wrote:
>
> On 2023/07/10 16:51, Ani Sinha wrote:
>>> On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote:
>>>
>>> The current implementers of ARI are all SR-IOV devices. The ARI next
>>> function number field is undefined for VF according to PCI
On 2023/07/10 16:51, Ani Sinha wrote:
On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote:
The current implementers of ARI are all SR-IOV devices. The ARI next
function number field is undefined for VF according to PCI Express Base
Specification Revision 5.0 Version 1.0 section 9.3.7.7. The PF
> On 05-Jul-2023, at 7:54 AM, Akihiko Odaki wrote:
>
> The current implementers of ARI are all SR-IOV devices. The ARI next
> function number field is undefined for VF according to PCI Express Base
> Specification Revision 5.0 Version 1.0 section 9.3.7.7. The PF should
> end the linked list
57 matches
Mail list logo
