On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote:
> Raise the maximum possible virtio transfer size to 128M
> (more precisely: 32k * PAGE_SIZE). See previous commit for a
> more detailed explanation for the reasons of this change.
>
> For not breaking any virtio user, all virt
On Mon, 4 Oct 2021 09:11:04 -0400
"Michael S. Tsirkin" wrote:
> > >> static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
> > >> {
> > >> #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
> > >> return virtio_is_big_endian(vdev);
> > >> #elif defined(TARGET_WORDS_BIGENDIAN)
> > >> if (
On 10/5/21 07:31, Peter Delevoryas wrote:
On Oct 4, 2021, at 12:49 AM, Cédric Le Goater wrote:
On 10/3/21 21:18, p...@fb.com wrote:
From: Andrew Jeffery
This model implements enough behaviour to do basic functionality tests
such as device initialisation and read out of dummy sample values.
On Tue, 5 Oct 2021 03:16:07 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote:
> > Raise the maximum possible virtio transfer size to 128M
> > (more precisely: 32k * PAGE_SIZE). See previous commit for a
> > more detailed explanation for the
On Mon, 4 Oct 2021 21:38:04 +0200
Christian Schoenebeck wrote:
> Refactor VIRTQUEUE_MAX_SIZE to effectively become a runtime
> variable per virtio user.
>
> Reasons:
>
> (1) VIRTQUEUE_MAX_SIZE should reflect the absolute theoretical
> maximum queue size possible. Which is actually the maxim
On 04.10.21 21:38, Christian Schoenebeck wrote:
At the moment the maximum transfer size with virtio is limited to 4M
(1024 * PAGE_SIZE). This series raises this limit to its maximum
theoretical possible transfer size of 128M (32k pages) according to the
virtio specs:
https://docs.oasis-open.org/
On Thu, Sep 30, 2021 at 04:05:52PM +0100, Daniel P. Berrangé wrote:
Co-incidentally we've just had another bug report filed today that
suggests 7bed89958bfbf40df9ca681cefbdca63abdde39d as a buggy commit
causing deadlock in QEMU
https://gitlab.com/qemu-project/qemu/-/issues/650
Is opening a gi
On Tue, Oct 05, 2021 at 09:25:39AM +0200, Halil Pasic wrote:
> On Mon, 4 Oct 2021 09:11:04 -0400
> "Michael S. Tsirkin" wrote:
>
> > > >> static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
> > > >> {
> > > >> #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
> > > >> return virtio_is_big
On Thu, Sep 16, 2021 at 2:21 PM Peter Lieven wrote:
>
> the qemu rbd driver currently lacks support for bdrv_co_block_status.
> This results mainly in incorrect progress during block operations (e.g.
> qemu-img convert with an rbd image as source).
>
> This patch utilizes the rbd_diff_iterate2 cal
At this moment vdpa will not send memory regions bigger than 1<<63.
However, actual iova range could be way more restrictive than that.
Since we can obtain the range through vdpa ioctl call, just save it
from the beginning of the operation and check against it.
Eugenio Pérez (3):
vdpa: Skip pro
Check vdpa device range before updating memory regions so we don't add
any outside of it, and report the invalid change if any.
Signed-off-by: Eugenio Pérez
---
include/hw/virtio/vhost-vdpa.h | 2 +
hw/virtio/vhost-vdpa.c | 68 ++
hw/virtio/trace-events
On 05/10/2021 17:42, Thomas Huth wrote:
On 05/10/2021 08.18, Alexey Kardashevskiy wrote:
On 05/10/2021 15:44, Christophe Leroy wrote:
Le 05/10/2021 à 02:48, David Gibson a écrit :
On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
On 01/10/2021 15.04, Christophe Leroy wrote:
Following the logic of commit 56918a126ae ("memory: Add RAM_PROTECTED
flag to skip IOMMU mappings") with VFIO, skip memory sections
inaccessible via normal mechanisms, including DMA.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/vi
On 10/4/21 10:38, Philippe Mathieu-Daudé wrote:
> Hardware emulated models don't belong to the TCG MAINTAINERS
> section. Move them to the 'HP-PARISC Machines' section.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Helge Deller
> ---
> MAINTAINERS | 5 ++---
> 1 file changed, 2 insert
On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
On 05/10/2021 17:42, Thomas Huth wrote:
On 05/10/2021 08.18, Alexey Kardashevskiy wrote:
On 05/10/2021 15:44, Christophe Leroy wrote:
Le 05/10/2021 à 02:48, David Gibson a écrit :
On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrot
Abstract this operation, that will be reused when validating the region
against the iova range that the device supports.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/hw/virtio/vhost-vdpa.c b/hw/vir
On Mon, Oct 04, 2021 at 03:58:09PM -0400, Vivek Goyal wrote:
> On Mon, Oct 04, 2021 at 02:54:17PM +0100, Stefan Hajnoczi wrote:
> > On Thu, Sep 30, 2021 at 11:30:30AM -0400, Vivek Goyal wrote:
> > > Add helpers to create/cleanup virtuqueues and use those helpers. I will
> >
> > s/virtuqueues/virtq
init_dirty_bitmap_migration assumes the iothread lock (BQL)
to be held, but instead it isn't.
Instead of adding the lock to qemu_savevm_state_setup(),
follow the same pattern as the other ->save_setup callbacks
and lock+unlock inside dirty_bitmap_save_setup().
Signed-off-by: Emanuele Giuseppe Esp
On Tue, Oct 05, 2021 at 10:01:30AM +0200, Eugenio Pérez wrote:
> Abstract this operation, that will be reused when validating the region
> against the iova range that the device supports.
>
> Signed-off-by: Eugenio Pérez
Note that as defined end is actually 1 byte beyond end of section.
As such
On Mon, Oct 04, 2021 at 05:01:07PM -0400, Vivek Goyal wrote:
> On Mon, Oct 04, 2021 at 03:30:38PM +0100, Stefan Hajnoczi wrote:
> > On Thu, Sep 30, 2021 at 11:30:32AM -0400, Vivek Goyal wrote:
> > > Add a notification queue which will be used to send async notifications
> > > for file lock availabi
On 10/5/21 08:18, Alexey Kardashevskiy wrote:
On 05/10/2021 15:44, Christophe Leroy wrote:
Le 05/10/2021 à 02:48, David Gibson a écrit :
On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
On 01/10/2021 15.04, Christophe Leroy wrote:
Le 01/10/2021 à 14:04, Thomas Huth a écrit :
Some functions (in this case qemu_savevm_state_complete_postcopy() and
init_dirty_bitmap_migration()) assume and document that
qemu_mutex_lock_iothread() is hold.
This seems to have been forgotten in some places, and this series
aims to fix that.
Patch 1 was part of my RFC block layer series "blo
Am 05.10.21 um 09:54 schrieb Ilya Dryomov:
On Thu, Sep 16, 2021 at 2:21 PM Peter Lieven wrote:
the qemu rbd driver currently lacks support for bdrv_co_block_status.
This results mainly in incorrect progress during block operations (e.g.
qemu-img convert with an rbd image as source).
This patch
On 10/4/21 23:52, John Snow wrote:
The series rotted already. Here's the new changes.
Signed-off-by: John Snow
Reviewed-by: Damien Hedde
---
docs/system/i386/sgx.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/system/i386/sgx.rst b/docs/system/i386/
qemu_savevm_state_complete_postcopy assumes the iothread lock (BQL)
to be held, but instead it isn't.
Signed-off-by: Emanuele Giuseppe Esposito
---
migration/migration.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/migration/migration.c b/migration/migration.c
index 041b8451a6..215d528
Thomas Huth writes:
> Some of the ObjectType entries already depend on CONFIG_* switches.
> Some others also only make sense with certain configurations, but
> are currently always listed in the ObjectType enum. Let's make them
> depend on the correpsonding CONFIG_* switches, too, so that upper
>
On Tue, Oct 05, 2021 at 10:01:31AM +0200, Eugenio Pérez wrote:
> Check vdpa device range before updating memory regions so we don't add
> any outside of it, and report the invalid change if any.
>
> Signed-off-by: Eugenio Pérez
> ---
> include/hw/virtio/vhost-vdpa.h | 2 +
> hw/virtio/vhost-vdp
On Tue, Oct 5, 2021 at 10:19 AM Peter Lieven wrote:
>
> Am 05.10.21 um 09:54 schrieb Ilya Dryomov:
> > On Thu, Sep 16, 2021 at 2:21 PM Peter Lieven wrote:
> >> the qemu rbd driver currently lacks support for bdrv_co_block_status.
> >> This results mainly in incorrect progress during block operati
This series upgrades the ACPI IORT table up to the E.b
specification revision. One of the goal of this upgrade
is to allow the addition of RMR nodes along with the SMMUv3.
It applies on top of Igor's
[PATCH v4 00/35] acpi: refactor error prone build_header() and
packed structures usage in ACPI tab
Upgrade the IORT table from B to E.b specification
revision (ARM DEN 0049E.b).
Signed-off-by: Eric Auger
---
v1 -> v2:
- Fix Revision value for ITS node and SMMUv3 node
- increment an identifier
---
hw/arm/virt-acpi-build.c | 48
1 file changed, 29 inse
Am 05.10.21 um 10:36 schrieb Ilya Dryomov:
On Tue, Oct 5, 2021 at 10:19 AM Peter Lieven wrote:
Am 05.10.21 um 09:54 schrieb Ilya Dryomov:
On Thu, Sep 16, 2021 at 2:21 PM Peter Lieven wrote:
the qemu rbd driver currently lacks support for bdrv_co_block_status.
This results mainly in incorrect
On Tue, Oct 05, 2021 at 10:40:00AM +0200, Cédric Le Goater wrote:
> > I'm curious if you go to
> >
> >https://gitlab.com/legoater/qemu/-/settings/ci_cd
> >
> > and expand "General pipelines", what value is set for the
> >
> >"Git shallow clone"
> >
> > setting. In my fork it is 0 which
Ignore IORT till reference blob for E.b spec revision gets
added.
Signed-off-by: Eric Auger
---
tests/qtest/bios-tables-test-allowed-diff.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523
I'm curious if you go to
https://gitlab.com/legoater/qemu/-/settings/ci_cd
and expand "General pipelines", what value is set for the
"Git shallow clone"
setting. In my fork it is 0 which means unlimited depth, but in
gitlab docs I see reference to repos getting this set to 50
since a pa
Re-generate reference blobs with rebuild-expected-aml.sh.
Signed-off-by: Eric Auger
---
tests/qtest/bios-tables-test-allowed-diff.h | 1 -
tests/data/acpi/virt/IORT | Bin 124 -> 128 bytes
tests/data/acpi/virt/IORT.memhp | Bin 124 -> 128 bytes
tests/data/acpi/vir
On 05/10/2021 10.07, Thomas Huth wrote:
On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
[...]
What is so special about taihu?
taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I
suggested to deprecate now)
I've now also played with the u-boot sources a little bit, and
Add a 'preserve_config' field in struct GPEXConfig and
if set generate the DSM #5 for preserving PCI boot configurations.
The DSM presence is needed to expose RMRs.
At the moment the DSM generation is not yet enabled.
Signed-off-by: Eric Auger
---
include/hw/pci-host/gpex.h | 1 +
hw/pci-host/
On [2021 Oct 04] Mon 17:46:33, Cédric Le Goater wrote:
> The register index is currently printed and this is confusing.
>
> Signed-off-by: Cédric Le Goater
Reviewed-by: Francisco Iglesias
> ---
> hw/ssi/aspeed_smc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
On Tue, Oct 05, 2021 at 06:44:23AM +0200, Christophe Leroy wrote:
>
>
> Le 05/10/2021 à 02:48, David Gibson a écrit :
> > On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
> > > On 01/10/2021 15.04, Christophe Leroy wrote:
> > > >
> > > >
> > > > Le 01/10/2021 à 14:04, Thomas Huth a
To handle SMMUv3 nested stage support it is practical to
expose the guest with reserved memory regions (RMRs)
covering the IOVAs used by the host kernel to map
physical MSI doorbells.
Those IOVAs belong to [0x800, 0x810] matching
MSI_IOVA_BASE and MSI_IOVA_LENGTH definitions in kernel
arm-
To handle SMMUv3 nested stage support it is practical to
expose the guest with reserved memory regions (RMRs)
covering the IOVAs used by the host kernel to map
physical MSI doorbells.
Those IOVAs belong to [0x800, 0x810] matching
MSI_IOVA_BASE and MSI_IOVA_LENGTH definitions in kernel
arm-
On [2021 Oct 04] Mon 17:46:32, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater
Reviewed-by: Francisco Iglesias
> ---
> hw/watchdog/wdt_aspeed.c | 5 +
> hw/watchdog/trace-events | 4
> 2 files changed, 9 insertions(+)
>
> diff --git a/hw/watchdog/wdt_aspeed.c b/hw/watchdog/
On 10/1/21 7:33 PM, Jean-Philippe Brucker wrote:
> To propagate errors to the caller of the pre_plug callback, use the
> object_poperty_set*() functions directly instead of the qdev_prop_set*()
> helpers.
>
> Suggested-by: Igor Mammedov
> Signed-off-by: Jean-Philippe Brucker
Reviewed-by: Eric
But actually OS X (macOS) supports 9pfs and it does have its own
AppleVirtIO9PVFS which makes things a bit strange, would not that be a
good workaround, to use the AppleVirtIO9PVFS?
All my best,
Waheed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is su
* Vivek Goyal (vgo...@redhat.com) wrote:
> Right now for xattr remapping, we support types of "prefix", "ok" or "bad".
> Type "bad" returns -EPERM on setxattr and hides xattr in listxattr. For
> getxattr, mapping code returns -EPERM but getxattr code converts it to
> -ENODATA.
>
> I need a new se
Le 04/10/2021 à 23:19, Mark Cave-Ayland a écrit :
> The monitor modes table is found by experimenting with the Monitors Control
> Panel in MacOS and analysing the reads/writes. From this it can be found that
> the mode is controlled by writes to the DAFB_MODE_CTRL1 and DAFB_MODE_CTRL2
> registers.
On Tue, Oct 5, 2021 at 10:15 AM Michael S. Tsirkin wrote:
>
> On Tue, Oct 05, 2021 at 10:01:30AM +0200, Eugenio Pérez wrote:
> > Abstract this operation, that will be reused when validating the region
> > against the iova range that the device supports.
> >
> > Signed-off-by: Eugenio Pérez
>
> No
On Tue, Oct 5, 2021 at 10:14 AM Michael S. Tsirkin wrote:
>
> On Tue, Oct 05, 2021 at 10:01:31AM +0200, Eugenio Pérez wrote:
> > Check vdpa device range before updating memory regions so we don't add
> > any outside of it, and report the invalid change if any.
> >
> > Signed-off-by: Eugenio Pérez
On Fri, 1 Oct 2021, Jean-Philippe Brucker wrote:
> The VIOT blob contains the following:
>
> [000h 4]Signature : "VIOT"[Virtual I/O
> Translation Table]
> [004h 0004 4] Table Length : 0058
> [008h 0008 1] Revision : 00
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:23:23AM +0200, Halil Pasic wrote:
>> --8<-
>>
>> From: Halil Pasic
>> Date: Thu, 30 Sep 2021 02:38:47 +0200
>> Subject: [PATCH] virtio: write back feature VERSION_1 before v
On Fri, 1 Oct 2021, Jean-Philippe Brucker wrote:
> Add expected blobs of the VIOT and DSDT table for the VIOT test on the
> q35 machine.
>
> Since the test instantiates a virtio device and two PCIe expander
> bridges, DSDT.viot has more blocks than the base DSDT (long diff not
> shown here).
F
This is a bugfix that stretches all the way back to January 2020,
where I initially introduced this problem and potential solutions.
A quick recap of the issue: QEMU did not sync up with the monitors
refresh rate causing the VM to render frames that were NOT displayed
to the user. That "fix" allow
* Emanuele Giuseppe Esposito (eespo...@redhat.com) wrote:
> qemu_savevm_state_complete_postcopy assumes the iothread lock (BQL)
> to be held, but instead it isn't.
>
> Signed-off-by: Emanuele Giuseppe Esposito
Interesting, I think you're right - and I think it's been missing it
from the start.
On Fri, 1 Oct 2021, Jean-Philippe Brucker wrote:
> Add two test cases for VIOT, one on the q35 machine and the other on
> virt. To test complex topologies the q35 test has two PCIe buses that
> bypass the IOMMU (and are therefore not described by VIOT), and two
> buses that are translated by vi
On Mon, 4 Oct 2021 05:07:13 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:23:23AM +0200, Halil Pasic wrote:
> > On Sat, 2 Oct 2021 14:13:37 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > > Anyone else have an idea? This is a nasty regression; we could revert
> > > > the
> >
On Tue, Oct 05, 2021 at 11:58:12AM +0200, Eugenio Perez Martin wrote:
> On Tue, Oct 5, 2021 at 10:14 AM Michael S. Tsirkin wrote:
> >
> > On Tue, Oct 05, 2021 at 10:01:31AM +0200, Eugenio Pérez wrote:
> > > Check vdpa device range before updating memory regions so we don't add
> > > any outside of
On Tue, 5 Oct 2021 03:53:17 -0400
"Michael S. Tsirkin" wrote:
> > Wouldn't a call from transport code into virtio core
> > be more handy? What I have in mind is stuff like vhost-user and vdpa. My
> > understanding is, that for vhost setups where the config is outside qemu,
> > we probably need a
On Tue, Oct 05, 2021 at 11:52:37AM +0200, Eugenio Perez Martin wrote:
> On Tue, Oct 5, 2021 at 10:15 AM Michael S. Tsirkin wrote:
> >
> > On Tue, Oct 05, 2021 at 10:01:30AM +0200, Eugenio Pérez wrote:
> > > Abstract this operation, that will be reused when validating the region
> > > against the i
Am 27.09.2021 um 12:33 hat Damien Hedde geschrieben:
> Hi Kevin,
>
> I proposed a very similar patch in our rfc series because we needed some of
> the cleaning you do here.
> https://lists.gnu.org/archive/html/qemu-devel/2021-09/msg05679.html
> I've added a bit of doc for the function, feel free t
On Dienstag, 5. Oktober 2021 09:38:53 CEST David Hildenbrand wrote:
> On 04.10.21 21:38, Christian Schoenebeck wrote:
> > At the moment the maximum transfer size with virtio is limited to 4M
> > (1024 * PAGE_SIZE). This series raises this limit to its maximum
> > theoretical possible transfer size
On Tue, Oct 05 2021, Halil Pasic wrote:
> On Mon, 4 Oct 2021 05:07:13 -0400
> "Michael S. Tsirkin" wrote:
>> Well we established that we can know. Here's an alternative explanation:
>
>
> I thin we established how this should be in the future, where a transport
> specific mechanism is used to de
On Tue, Oct 05, 2021 at 12:43:03PM +0200, Halil Pasic wrote:
> On Mon, 4 Oct 2021 05:07:13 -0400
> "Michael S. Tsirkin" wrote:
>
> > On Mon, Oct 04, 2021 at 04:23:23AM +0200, Halil Pasic wrote:
> > > On Sat, 2 Oct 2021 14:13:37 -0400
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > > Anyone el
On Dienstag, 5. Oktober 2021 09:16:07 CEST Michael S. Tsirkin wrote:
> On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote:
> > Raise the maximum possible virtio transfer size to 128M
> > (more precisely: 32k * PAGE_SIZE). See previous commit for a
> > more detailed explanation fo
On Tue, Oct 05, 2021 at 01:10:56PM +0200, Christian Schoenebeck wrote:
> On Dienstag, 5. Oktober 2021 09:38:53 CEST David Hildenbrand wrote:
> > On 04.10.21 21:38, Christian Schoenebeck wrote:
> > > At the moment the maximum transfer size with virtio is limited to 4M
> > > (1024 * PAGE_SIZE). This
On Tue, Oct 05, 2021 at 12:46:34PM +0200, Halil Pasic wrote:
> On Tue, 5 Oct 2021 03:53:17 -0400
> "Michael S. Tsirkin" wrote:
>
> > > Wouldn't a call from transport code into virtio core
> > > be more handy? What I have in mind is stuff like vhost-user and vdpa. My
> > > understanding is, that f
On Tue, Oct 05, 2021 at 01:13:31PM +0200, Cornelia Huck wrote:
> On Tue, Oct 05 2021, Halil Pasic wrote:
>
> > On Mon, 4 Oct 2021 05:07:13 -0400
> > "Michael S. Tsirkin" wrote:
> >> Well we established that we can know. Here's an alternative explanation:
> >
> >
> > I thin we established how thi
On Tue, Oct 05, 2021 at 01:17:59PM +0200, Christian Schoenebeck wrote:
> On Dienstag, 5. Oktober 2021 09:16:07 CEST Michael S. Tsirkin wrote:
> > On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote:
> > > Raise the maximum possible virtio transfer size to 128M
> > > (more precisel
On 05/10/2021 10:50, Laurent Vivier wrote:
Le 04/10/2021 à 23:19, Mark Cave-Ayland a écrit :
The monitor modes table is found by experimenting with the Monitors Control
Panel in MacOS and analysing the reads/writes. From this it can be found that
the mode is controlled by writes to the DAFB_MOD
On Mon, 4 Oct 2021 16:13:09 -0500
Eric DeVolder wrote:
> Igor, thanks for the close examination. Inline responses below.
> eric
>
> On 9/21/21 10:30 AM, Igor Mammedov wrote:
> > On Thu, 5 Aug 2021 18:30:34 -0400
> > Eric DeVolder wrote:
> >
> >> This implements a PCI device for ACPI ERST. T
On Dienstag, 5. Oktober 2021 13:19:43 CEST Michael S. Tsirkin wrote:
> On Tue, Oct 05, 2021 at 01:10:56PM +0200, Christian Schoenebeck wrote:
> > On Dienstag, 5. Oktober 2021 09:38:53 CEST David Hildenbrand wrote:
> > > On 04.10.21 21:38, Christian Schoenebeck wrote:
> > > > At the moment the maxim
On Mon, Oct 04, 2021 at 11:27:12AM +0200, Philippe Mathieu-Daudé wrote:
On 10/4/21 11:23, Stefan Hajnoczi wrote:
On Mon, Sep 06, 2021 at 12:43:17PM +0200, Philippe Mathieu-Daudé wrote:
vring_get_region_caches() must be called with the RCU read lock
acquired. virtqueue_packed_drop_all() does not
Hi jean,
On 10/1/21 7:33 PM, Jean-Philippe Brucker wrote:
> We're about to need this check for a third vIOMMU, virtio-iommu, which
> doesn't inherit X86IOMMUState as it doesn't support IRQ remapping and is
> a virtio device. Move the check into the pre_plug callback to be shared
> by all three vIO
Hi Jean,
On 10/1/21 7:33 PM, Jean-Philippe Brucker wrote:
> virtio-iommu is now supported with ACPI VIOT as well as device tree.
> Remove the restriction that prevents from instantiating a virtio-iommu
> device under ACPI.
>
> Reviewed-by: Eric Auger
> Signed-off-by: Jean-Philippe Brucker
> ---
On Tue, 05 Oct 2021 13:13:31 +0200
Cornelia Huck wrote:
> On Tue, Oct 05 2021, Halil Pasic wrote:
>
> > On Mon, 4 Oct 2021 05:07:13 -0400
> > "Michael S. Tsirkin" wrote:
> >> Well we established that we can know. Here's an alternative explanation:
> >
> >
> > I thin we established how this
On Dienstag, 5. Oktober 2021 13:24:36 CEST Michael S. Tsirkin wrote:
> On Tue, Oct 05, 2021 at 01:17:59PM +0200, Christian Schoenebeck wrote:
> > On Dienstag, 5. Oktober 2021 09:16:07 CEST Michael S. Tsirkin wrote:
> > > On Mon, Oct 04, 2021 at 09:38:08PM +0200, Christian Schoenebeck wrote:
> > > >
On Tue, 5 Oct 2021, Thomas Huth wrote:
On 05/10/2021 10.07, Thomas Huth wrote:
On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
[...]
What is so special about taihu?
taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I
suggested to deprecate now)
I've now also played wi
On Tue, 5 Oct 2021, Cédric Le Goater wrote:
On 10/5/21 08:18, Alexey Kardashevskiy wrote:
On 05/10/2021 15:44, Christophe Leroy wrote:
Le 05/10/2021 à 02:48, David Gibson a écrit :
On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
On 01/10/2021 15.04, Christophe Leroy wrote:
Le 01
On Thu, Sep 30, 2021 at 11:30:37AM -0400, Vivek Goyal wrote:
> g_usleep() calls nanosleep() and that now seems to call clock_nanosleep()
> syscall. Now these patches are making use of g_usleep(). So add
> clock_nanosleep() to list of allowed syscalls.
>
> Signed-off-by: Vivek Goyal
> ---
> tools
On Thu, Sep 30, 2021 at 11:30:36AM -0400, Vivek Goyal wrote:
> As of now we don't support fcntl(F_SETLKW) and if we see one, we return
> -EOPNOTSUPP.
>
> Change that by accepting these requests and returning a reply
> immediately asking caller to wait. Once lock is available, send a
> notification
On 05/10/2021 14.20, BALATON Zoltan wrote:
On Tue, 5 Oct 2021, Cédric Le Goater wrote:
On 10/5/21 08:18, Alexey Kardashevskiy wrote:
On 05/10/2021 15:44, Christophe Leroy wrote:
Le 05/10/2021 à 02:48, David Gibson a écrit :
On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
On 01/1
On 05/10/2021 14.17, BALATON Zoltan wrote:
On Tue, 5 Oct 2021, Thomas Huth wrote:
On 05/10/2021 10.07, Thomas Huth wrote:
On 05/10/2021 10.05, Alexey Kardashevskiy wrote:
[...]
What is so special about taihu?
taihu is the other 405 board defined in hw/ppc/ppc405_boards.c (which I
suggested
On Tue, Oct 05, 2021 at 09:14:14AM +0100, Stefan Hajnoczi wrote:
> On Mon, Oct 04, 2021 at 05:01:07PM -0400, Vivek Goyal wrote:
> > On Mon, Oct 04, 2021 at 03:30:38PM +0100, Stefan Hajnoczi wrote:
> > > On Thu, Sep 30, 2021 at 11:30:32AM -0400, Vivek Goyal wrote:
> > > > Add a notification queue wh
On Mon, Oct 04, 2021 at 09:38:04PM +0200, Christian Schoenebeck wrote:
> Refactor VIRTQUEUE_MAX_SIZE to effectively become a runtime
> variable per virtio user.
virtio user == virtio device model?
>
> Reasons:
>
> (1) VIRTQUEUE_MAX_SIZE should reflect the absolute theoretical
> maximum queu
On Mon, Oct 04, 2021 at 03:54:31PM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 30, 2021 at 11:30:34AM -0400, Vivek Goyal wrote:
> > Add a new custom threadpool using posix threads that specifically
> > service locking requests.
> >
> > In the case of a fcntl(SETLKW) request, if the guest is waitin
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Saturday, October 2, 2021 7:05 AM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
>
> Cc: phi...@redhat.com; pbonz...@redhat.com; marcel.apfelb...@gmail.com;
> m...@redhat.com; qem
On Tue, Oct 5, 2021 at 12:47 PM Michael S. Tsirkin wrote:
>
> On Tue, Oct 05, 2021 at 11:52:37AM +0200, Eugenio Perez Martin wrote:
> > On Tue, Oct 5, 2021 at 10:15 AM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Oct 05, 2021 at 10:01:30AM +0200, Eugenio Pérez wrote:
> > > > Abstract this operat
On Dienstag, 5. Oktober 2021 14:45:56 CEST Stefan Hajnoczi wrote:
> On Mon, Oct 04, 2021 at 09:38:04PM +0200, Christian Schoenebeck wrote:
> > Refactor VIRTQUEUE_MAX_SIZE to effectively become a runtime
> > variable per virtio user.
>
> virtio user == virtio device model?
Yes
> > Reasons:
> >
>
Add docs/specs/sev-guest-firmware.rst which describes the GUIDed table
in the end of OVMF's image which is parsed by QEMU, and currently used
to describe some values for SEV and SEV-ES guests.
Signed-off-by: Dov Murik
---
docs/specs/index.rst | 1 +
docs/specs/sev-guest-firmware.r
On 9/16/21 13:17, Markus Armbruster wrote:
Commit 6287d827d4 "monitor: allow device_del to accept QOM paths"
extended find_device_state() to accept QOM paths in addition to qdev
IDs. This added a checked conversion to TYPE_DEVICE at the end, which
duplicates the check done for the qdev ID cas
On Mon, Oct 04, 2021 at 04:07:04PM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 30, 2021 at 11:30:36AM -0400, Vivek Goyal wrote:
> > As of now we don't support fcntl(F_SETLKW) and if we see one, we return
> > -EOPNOTSUPP.
> >
> > Change that by accepting these requests and returning a reply
> > imm
On Mon, Oct 04, 2021 at 02:34:49PM -0500, Michael Roth wrote:
> Quoting Stefan Hajnoczi (2021-10-04 04:01:22)
> > On Fri, Oct 01, 2021 at 09:39:13AM +0200, Philippe Mathieu-Daudé wrote:
> > > On 9/30/21 15:40, Stefan Hajnoczi wrote:
> > > > Hi Mike,
> > > > QEMU downloads are currently hosted on qe
On Mon, Oct 04, 2021 at 04:01:02PM +0100, Stefan Hajnoczi wrote:
> On Thu, Sep 30, 2021 at 11:30:35AM -0400, Vivek Goyal wrote:
> > So far we did not have the notion of cross queue traffic. That is, we
> > get request on a queue and send back response on same queue. So if a
> > request be being pro
This device is part of a superio/ISA bridge chip and IRQs from it are
routed to an ISA interrupt set by the Interrupt Line PCI config
register. Change uhci_update_irq() to allow this and use it from
vt82c686-uhci-pci.
Signed-off-by: BALATON Zoltan
Reviewed-by: Jiaxun Yang
---
v2: Do it different
On 2021-09-30 at 11:30 -04, Vivek Goyal wrote...
> We are emulating posix locks for guest using open file description locks
> in virtiofsd. When any of the fd is closed in guest, we find associated
> OFD lock fd (if there is one) and close it to release all the locks.
>
> Assumption here is that
Following the logic of commit 56918a126ae ("memory: Add RAM_PROTECTED
flag to skip IOMMU mappings") with VFIO, skip memory sections
inaccessible via normal mechanisms, including DMA.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/vi
Kevin Wolf writes:
> Am 02.10.2021 um 15:33 hat Markus Armbruster geschrieben:
>> I apologize for this wall of text. It's a desparate attempt to cut
>> through the complexity and my confusion, and make sense of the actual
>> problems we're trying to solve.
>>
>> So, what problems exactly are we
At this moment vdpa will not send memory regions bigger than 1<<63.
However, actual iova range could be way more restrictive than that.
Since we can obtain the range through vdpa ioctl call, just save it
from the beginning of the operation and check against it.
Changes from v1:
* Use of int128_gt
Check vdpa device range before updating memory regions so we don't add
any outside of it, and report the invalid change if any.
Signed-off-by: Eugenio Pérez
---
include/hw/virtio/vhost-vdpa.h | 2 +
hw/virtio/vhost-vdpa.c | 68 ++
hw/virtio/trace-events
Abstract this operation, that will be reused when validating the region
against the iova range that the device supports.
Signed-off-by: Eugenio Pérez
---
hw/virtio/vhost-vdpa.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/hw/virtio/vhost-vdpa.c b/hw
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Tue, Oct 05, 2021 at 02:18:40AM +0300, Roman Kagan wrote:
> > On Mon, Oct 04, 2021 at 11:11:00AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Oct 04, 2021 at 06:07:29PM +0300, Denis Plotnikov wrote:
> > > > It might be useful for the cases when a
1 - 100 of 300 matches
Mail list logo
