On 23.12.2019 17:31, Michael S. Tsirkin wrote:
> On Mon, Dec 23, 2019 at 02:37:58PM +0300, Denis Plotnikov wrote:
>> Currenly, the virtqueue size is saved to the proxy on pci writing and
>> is read from the device pci reading.
>> The virtqueue size is propagated later on form the proxy to the dev
Hi Peter,
On 12/10/19 9:01 PM, Peter Xu wrote:
> On Fri, Nov 22, 2019 at 07:29:41PM +0100, Eric Auger wrote:
>> +static const VMStateDescription vmstate_virtio_iommu_device = {
>> +.name = "virtio-iommu-device",
>> +.minimum_version_id = 1,
>> +.version_id = 1,
>> +.post_load = iom
Hi Jean,
On 12/10/19 5:50 PM, Jean-Philippe Brucker wrote:
> On Fri, Nov 22, 2019 at 07:29:42PM +0100, Eric Auger wrote:
>> The virtio-iommu-pci is instantiated through the -device QEMU
>> option. However if instantiated it also requires an IORT ACPI table
>> to describe the ID mappings between th
Le 24/12/2019 à 05:33, Finn Thain a écrit :
On Tue, 24 Dec 2019, Finn Thain wrote:
I know precious little about NetBSD installation and MIPS Magnum. What I
wrote above was guesswork. Hence this could be a NetBSD bug or user
error.
It was bugs and user error.
The user error was not using th
On Mon, Dec 23, 2019 at 08:27:49PM -0300, Fabiano Rosas wrote:
> David Gibson writes:
>
> > b) AFAICT this is the *only* thing that looks for the LE bit in
> > hflags. Given that, and the fact that it would be wrong in most cases,
> > we should remove it from hflags entirely along with this chang
On Mon, Dec 23, 2019 at 06:35:30PM -0300, Maxiwell S. Garcia wrote:
> On Mon, Dec 23, 2019 at 05:30:43PM +1100, David Gibson wrote:
> > On Thu, Dec 19, 2019 at 01:38:54PM -0300, Maxiwell S. Garcia wrote:
> > > The env->hflags is computed in ppc_cpu_reset(), using the MSR register
> > > as input. Bu
From: Aleksandar Markovic
Update mips syscall numbers based on Linux kernel tag v5.5-rc3
(commit 46cf053e).
Signed-off-by: Aleksandar Markovic
---
linux-user/mips/cpu_loop.c | 69 ++
linux-user/mips/syscall_nr.h | 45 +++
li
From: Aleksandar Markovic
Some constants were defined in terms of host, instead of target,
as they should be.
Some additional trivial changes in this patch were forced by
checkpatch.pl.
Reviewed-by: Max Filippov
Signed-off-by: Aleksandar Markovic
---
linux-user/aarch64/termbits.h| 4 +-
From: Aleksandar Markovic
This series is a collection of patches I recently accumulated.
v1->v2:
- fixed a constant in xtensa's termbits.h that was missed in v1
- redid syscall numbers for mips o32
- minor formatting and wording changes
Aleksandar Markovic (6):
linux-user: Fix some con
From: Aleksandar Markovic
These FS_IOC32_VERSION ioctls are identical to
FS_IOC_VERSION ioctls, but without the anomaly of their
number defined as if their third argument is of type long, while
it is treated internally in kernel as is of type int.
Signed-off-by: Aleksandar Markovic
---
linux-u
From: Aleksandar Markovic
These ioctls were relatively recently introduced, so the "#ifdef"
guards are used in this implementation.
Signed-off-by: Aleksandar Markovic
---
linux-user/ioctls.h | 7 +++
linux-user/syscall_defs.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/lin
From: Aleksandar Markovic
A very specific thing for these two ioctls is that their code
implies that their third argument is of type 'long', but the
kernel uses that argument as if it is of type 'int'. This anomaly
is recognized also in commit 6080723 (linux-user: Implement
FS_IOC_GETFLAGS and FS
From: Aleksandar Markovic
These FS_IOC32_FLAGS ioctls are identical to
FS_IOC_FLAGS ioctls, but without the anomaly of their
number defined as if their third argument is of type long, while
it is treated internally in kernel as is of type int.
Signed-off-by: Aleksandar Markovic
---
linux-user/
On Tue, 24 Dec 2019, Finn Thain wrote:
>
> I know precious little about NetBSD installation and MIPS Magnum. What I
> wrote above was guesswork. Hence this could be a NetBSD bug or user
> error.
>
It was bugs and user error.
The user error was not using the serial console. The NetBSD/arc
in
On 24.12.2019 03:20, John Snow wrote:
> On 12/19/19 10:01 AM, Kevin Wolf wrote:
>>
>> John, what do you think?
>>
>
> I've been out to lunch for a little while. There are some issues that I
> recall with IDE, but couldn't find the time to fix prior to 4.2.
Hello John.
> I'll review all the outst
> > -#define TARGET_TIOCMIWAIT _IO('T', 92) /* wait for a change on serial
> > input line(s) */
> > -#define TARGET_TIOCGICOUNT 0x545D /* read serial port inline interrupt
> > counts */
> > +/* wait for a change on serial input line(s) */
> > +#define TARGET_TIOCMIWAIT _IO('T', 92)
>
> This o
On Mon, Dec 23, 2019 at 6:45 PM Aleksandar Markovic
wrote:
>
> From: Aleksandar Markovic
>
> Some constants were defined in terms of host, instead of target,
> as they should be.
>
> Some additional trivial changes in this patch were forced by
> checkpatch.pl.
>
> Signed-off-by: Aleksandar Markov
From: Aleksandar Markovic
Some constants were defined in terms of host, instead of target,
as they should be.
Some additional trivial changes in this patch were forced by
checkpatch.pl.
Signed-off-by: Aleksandar Markovic
---
linux-user/aarch64/termbits.h| 4 +-
linux-user/alpha/termbits
From: Aleksandar Markovic
A very specific thing for these two ioctls is that thier code
implies that their third argument is of type long, but the kernel
uses that argument as if it is of type int. This anomaly is
recognized also in commit 6080723 (linux-user: Implement
FS_IOC_GETFLAGS and FS_IOC
From: Aleksandar Markovic
These FS_IOC32_VERSION ioctls are identical to
FS_IOC_VERSION ioctls, but without the anomaly of their
number defined as if their third argument is of type long, while
it is treated internally in kernel as is of type int.
Signed-off-by: Aleksandar Markovic
---
linux-u
From: Aleksandar Markovic
Update mips syscall numbers based on Linux kernel tag v5.5-rc3
(commit 46cf053e).
Signed-off-by: Aleksandar Markovic
---
linux-user/mips/cpu_loop.c | 41 ++
linux-user/mips/syscall_nr.h | 45 +++
From: Aleksandar Markovic
This series is a collection of patches I recently accumulated.
Aleksandar Markovic (5):
linux-user: Fix some constants in termbits.h
linux-user: mips: Update syscall numbers to kernel 5.5 rc3 level
linux-user: Add support for FS_IOC_VERSION ioctls
linux-user: Ad
From: Aleksandar Markovic
These FS_IOC32_FLAGS ioctls are identical to
FS_IOC_FLAGS ioctls, but without the anomaly of their
number defined as if their third argument is of type long, while
it is treated internally in kernel as is of type int.
Signed-off-by: Aleksandar Markovic
---
linux-user/
On 12/19/19 10:01 AM, Kevin Wolf wrote:
> Am 16.12.2019 um 19:14 hat Alexander Popov geschrieben:
>> The commit a718978ed58a from July 2015 introduced the assertion which
>> implies that the size of successful DMA transfers handled in ide_dma_cb()
>> should be multiple of 512 (the size of a sect
On 12/23/19 6:50 PM, Sven Schnelle wrote:
Hi Philippe,
On Sun, Dec 22, 2019 at 01:37:48PM +0100, Philippe Mathieu-Daudé wrote:
+if (vga_interface_type != VGA_NONE) {
+dev = qdev_create(NULL, "artist");
+qdev_init_nofail(dev);
+s = SYS_BUS_DEVICE(dev);
+sys
On Mon, 23 Dec 2019, Philippe Mathieu-Daud? wrote:
> Hi Finn,
>
> On 12/20/19 5:24 AM, Finn Thain wrote:
> > On Sun, 15 Dec 2019, Aleksandar Markovic wrote:
> >
> > >
> > > Herve,
> > >
> > > Is there any way for us to come up with an equivalent or at least
> > > approximate scenario for Jazz
Hi Paolo,
On 10/16/19 11:29 AM, Paolo Bonzini wrote:
On 16/10/19 11:26, Philippe Mathieu-Daudé wrote:
On 10/16/19 9:46 AM, Paolo Bonzini wrote:
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index c5c9d4900e..d399dcba52 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -92,6 +92,10 @@ co
On 12/19/19 9:42 AM, Max Reitz wrote:
> First, driver=qcow2 will not work so well with non-qcow2 formats (and
> this test claims to support qcow, qed, and vmdk).
>
> Second, vmdk will always report the backing file format to be vmdk.
> Filter that out so the output looks like for all other form
David Gibson writes:
> b) AFAICT this is the *only* thing that looks for the LE bit in
> hflags. Given that, and the fact that it would be wrong in most cases,
> we should remove it from hflags entirely along with this change.
>
I see there is:
static void ppc_tr_init_disas_context(DisasContext
On 12/19/19 1:36 PM, Max Reitz wrote:
> The "migration completed" event may be sent (on the source, to be
> specific) before the migration is actually completed, so the VM runstate
> will still be "finish-migrate" instead of "postmigrate". So ask the
> users of VM.wait_migration() to specify th
I will try to debug as time permits, but the priority of MS-DOS bugs is
not ... measurable with casual tools. However, there are a lot of other
IDE bugs on my plate that are very important! so I am hoping to grab a
bunch of IDE bugs at once, but no promises here.
Notably, our geometry detection is
On Mon, Dec 23, 2019 at 05:30:43PM +1100, David Gibson wrote:
> On Thu, Dec 19, 2019 at 01:38:54PM -0300, Maxiwell S. Garcia wrote:
> > The env->hflags is computed in ppc_cpu_reset(), using the MSR register
> > as input. But at the point ppc_disas_set_info() is called the MSR_LE bit
> > in env->hfl
*** This bug is a duplicate of bug 1776920 ***
https://bugs.launchpad.net/bugs/1776920
Does the problem happen only when the image is on APFS? when the
destination is on APFS? Neither? Try to see if it's the filesystem. Use
OSX to convert images on a non-APFS formatted external drive to see if
Hi, versions 2.5 and 2.11 are quite old (though version 2.10 fixed the
bug mentioned in the Red Hat BZ, so I think this might be a different
bug.)
It's not clear at what step this is failing or where you are seeing the error
message, so:
1. What is your full command line for QEMU?
2. Do you see
OK, so we're only talking about migrating a disk and not a whole VM, I
misunderstood. However... are you using qemu *2.7*? That's quite old!
Before digging into this further I need to insist that you try on a
supported release, either 4.0.1, 4.1.1, or 4.2.0.
** Changed in: qemu
Status: New
Hi, qemu version 3.1 is a bit old in terms of upstream support. Can you
confirm that this is still an issue on 4.2 ?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.la
For now, QEMU cannot accept images with extra bitmap data, because QEMU
isn't aware of the semantics of those fields, so we cannot even allow
the image to load, just in case.
However, we SHOULD allow qemu-img check --repair to detect such bitmaps
as corruption so that images can be scrubbed and re
Hi, this should be fixed in 4.2. It looks like you're still on 2.12.0
based on the report. Closing under the assumption this is fixed. If you
discover otherwise, please feel free to re-open (or file a new bug.)
** Changed in: qemu
Status: Confirmed => Fix Released
--
You received this bug
Fuzzing the Linux kernel with syzkaller allowed to find how to crash qemu
using a special SCSI_IOCTL_SEND_COMMAND. It hits the assertion in
ide_dma_cb() introduced in the commit a718978ed58a in July 2015.
Currently this bug is not reproduced by the unit tests.
Let's improve the ide-test to cover m
Fuzzing the Linux kernel with syzkaller allowed to find how to crash qemu
using a special SCSI_IOCTL_SEND_COMMAND. It hits the assertion in
ide_dma_cb() introduced in the commit a718978ed58a in July 2015.
This patch series fixes incorrect handling of some PRDTs in ide_dma_cb()
and improves the ide
The commit a718978ed58a from July 2015 introduced the assertion which
implies that the size of successful DMA transfers handled in ide_dma_cb()
should be multiple of 512 (the size of a sector). But guest systems can
initiate DMA transfers that don't fit this requirement.
For fixing that let's chec
Hi Philippe,
On Sun, Dec 22, 2019 at 01:37:48PM +0100, Philippe Mathieu-Daudé wrote:
> >
> > +if (vga_interface_type != VGA_NONE) {
> > +dev = qdev_create(NULL, "artist");
> > +qdev_init_nofail(dev);
> > +s = SYS_BUS_DEVICE(dev);
> > +sysbus_mmio_map(s, 0, LAS
On 23/12/19 15:25, Michael S. Tsirkin wrote:
> On Mon, Dec 23, 2019 at 12:02:18PM +0100, Paolo Bonzini wrote:
>> On 23/12/19 10:18, Yang Zhong wrote:
>>> In this time, the queue number in the front-end block driver is 2, but
>>> the queue number in qemu side is still 4. So the guest virtio_blk
Hi Finn,
On 12/20/19 5:24 AM, Finn Thain wrote:
On Sun, 15 Dec 2019, Aleksandar Markovic wrote:
Herve,
Is there any way for us to come up with an equivalent or at least
approximate scenario for Jazz machines?
Regards,
Aleksandar
That would be useful in general, but in this case I think i
From: Denis Plotnikov
Before the patch, seg_max parameter was immutable and hardcoded
to 126 (128 - 2) without respect to queue size. This has two negative effects:
1. when queue size is < 128, we have Virtio 1.1 specfication violation:
(2.6.5.3.1 Driver Requirements) seq_max must be <= queue
From: Denis Plotnikov
5.0 machine type uses 4.2 compats. This seems to be incorrect, since
the latests machine type by now is 5.0 and it should use its own
compat or shouldn't use any relying on the defaults.
Seems, like this appeared because of some problems on merge/rebase.
Signed-off-by: Deni
From: Raphael Norwitz
Add a VHOST_USER_RESET_DEVICE message which will reset the vhost user
backend. Disabling all rings, and resetting all internal state, ready
for the backend to be reinitialized.
A backend has to report it supports this features with the
VHOST_USER_PROTOCOL_F_RESET_DEVICE pro
The following changes since commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc:
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20191219' into
staging (2019-12-20 16:37:07 +)
are available in the Git repository at:
git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstrea
From: Raphael Norwitz
If the vhost-user-scsi backend supports the VHOST_USER_F_RESET_DEVICE
protocol feature, then the device can be reset when requested.
If this feature is not supported, do not try a reset as this will send
a VHOST_USER_RESET_OWNER that the backend is not expecting,
potentiall
From: Philippe Mathieu-Daudé
Both functions are called by MemoryRegionOps.[read/write] handlers
with unsigned 'size' argument. Both functions call
pci_host_config_[read/write]_common() which expect a uint32_t 'len'
parameter (also unsigned).
Since it is pointless (and confuse) to use a signed val
Signed-off-by: Michael S. Tsirkin
---
tests/bios-tables-test-allowed-diff.h | 8
tests/data/acpi/pc/APIC.acpihmat | Bin 0 -> 128 bytes
tests/data/acpi/pc/DSDT.acpihmat | Bin 0 -> 6455 bytes
tests/data/acpi/pc/HMAT.acpihmat | Bin 0 -> 280 bytes
tests/data/acpi/pc/SRAT.
From: Denis Plotnikov
It tests proper seg_max_adjust settings for all machine types except
'none', 'isapc', 'microvm'
Signed-off-by: Denis Plotnikov
Message-Id: <20191220140905.1718-3-dplotni...@virtuozzo.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
tests/accept
From: Tao Xu
Check configuring HMAT usecase
Acked-by: Markus Armbruster
Suggested-by: Igor Mammedov
Signed-off-by: Tao Xu
Message-Id: <20191213011929.2520-8-tao3...@intel.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Igor Mammedov
---
tests/numa-test.
From: Liu Jingqi
This structure describes memory side cache information for memory
proximity domains if the memory side cache is present and the
physical device forms the memory side cache.
The software could use this information to effectively place
the data in memory to maximize the performance
From: Philippe Mathieu-Daudé
In commit 3bf4dfdd111 we introduced the pci_cfg_[read/write]
trace events in pci_host_config_[read/write]_common().
We have the following call trace:
pci_host_data_[read/write]()
- PCI_DPRINTF()
- pci_data_[read/write]()
- PCI_DPRINTF()
- pc
From: Jean-Philippe Brucker
At the moment when the guest writes a status of 0, we only reset the
virtio core state but not the virtio-mmio state. The virtio-mmio
specification says (v1.1 cs01, 4.2.2.1 Device Requirements:
MMIO Device Register Layout):
Upon reset, the device MUST clear all bi
From: Liu Jingqi
This structure describes the memory access latency and bandwidth
information from various memory access initiator proximity domains.
The latency and bandwidth numbers represented in this structure
correspond to rated latency and bandwidth for the platform.
The software could use
Some guests read back queue size after writing it.
Update the size immediatly upon write otherwise
they get confused.
Signed-off-by: Michael S. Tsirkin
---
hw/virtio/virtio-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index c6b47a9c7
From: Tao Xu
ACPI table HMAT has been introduced, QEMU now builds HMAT tables for
Heterogeneous Memory with boot option '-numa node'.
Add test cases on PC and Q35 machines with 2 numa nodes.
Because HMAT is generated when system enable numa, the
following tables need to be added for this test:
From: Liu Jingqi
Add -numa hmat-lb option to provide System Locality Latency and
Bandwidth Information. These memory attributes help to build
System Locality Latency and Bandwidth Information Structure(s)
in ACPI Heterogeneous Memory Attribute Table (HMAT). Before using
hmat-lb option, enable HMA
From: Liu Jingqi
Add -numa hmat-cache option to provide Memory Side Cache Information.
These memory attributes help to build Memory Side Cache Information
Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT).
Before using hmat-cache option, enable HMAT with -machine hmat=on.
Acked-by
From: Micky Yun Chan
This patch is to add standard commands defined in docs/interop/vhost-user.rst
For vhost-user-* program
Signed-off-by: Micky Yun Chan (michiboo)
Message-Id: <20191209015331.5455-1-chanmicky...@gmail.com>
Reviewed-by: Michael S. Tsirkin
Signed-off-by: Michael S. Tsirkin
---
From: Liu Jingqi
HMAT is defined in ACPI 6.3: 5.2.27 Heterogeneous Memory Attribute Table
(HMAT). The specification references below link:
http://www.uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
It describes the memory attributes, such as memory side cache
attributes and bandw
From: Yi Sun
Should directly read DMAR_RTADDR_REG but not using 's->root'.
Because 's->root' is modified in 'vtd_root_table_setup()' so
that the first 12 bits are omitted. This causes the guest
iommu debugfs cannot show pasid tables.
Signed-off-by: Yi Sun
Message-Id: <20191205095439.29114-1-yi.
From: Pan Nengyuan
ivq/dvq/svq/free_page_vq is forgot to cleanup in
virtio_balloon_device_unrealize, the memory leak stack is as follow:
Direct leak of 14336 byte(s) in 2 object(s) allocated from:
#0 0x7f99fd9d8560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7f99fcb20015 in g_malloc
From: Tao Xu
In ACPI 6.3 chapter 5.2.27 Heterogeneous Memory Attribute Table (HMAT),
The initiator represents processor which access to memory. And in 5.2.27.3
Memory Proximity Domain Attributes Structure, the attached initiator is
defined as where the memory controller responsible for a memory p
From: Michael Roth
Currently the SLOF firmware for pseries guests will disable/re-enable
a PCI device multiple times via IO/MEM/MASTER bits of PCI_COMMAND
register after the initial probe/feature negotiation, as it tends to
work with a single device at a time at various stages like probing
and ru
Seems cleaner than using VQ index values.
Signed-off-by: Michael S. Tsirkin
---
hw/input/virtio-input.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/input/virtio-input.c b/hw/input/virtio-input.c
index ec54e46ad6..9c013afddb 100644
--- a/hw/input/virtio-input.c
+++
From: Pan Nengyuan
ivqs/ovqs/c_ivq/c_ovq is forgot to cleanup in
virtio_serial_device_unrealize, the memory leak stack is as bellow:
Direct leak of 1290240 byte(s) in 180 object(s) allocated from:
#0 0x7fc9bfc27560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7fc9bed6f015 in g_malloc
From: Stefan Hajnoczi
Virtqueue notifications are not necessary during polling, so we disable
them. This allows the guest driver to avoid MMIO vmexits.
Unfortunately the virtio-blk and virtio-scsi handler functions re-enable
notifications, defeating this optimization.
Fix virtio-blk and virtio-
Let's make sure calling this twice is harmless -
no known instances, but seems safer.
Suggested-by: Pan Nengyuan
Signed-off-by: Michael S. Tsirkin
---
hw/virtio/virtio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 31dd140990..6de3cfdc2c 1006
Devices tend to maintain vq pointers, allow deleting them trough a vq pointer.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: David Hildenbrand
Reviewed-by: David Hildenbrand
---
include/hw/virtio/virtio.h | 2 ++
hw/virtio/virtio.c | 15 ++-
2 files changed, 12 insertions
Damir,
We normally test Linux guests here. Can you please give me exact qemu command
line. Even the SMP parameters(sockets,cores,threads,dies) will also work. I
will try to recreate it locally first.
Give me example what works and what does not work.
I have recently sent few more patches to fi
On 12/21/19 10:02 AM, Markus Armbruster wrote:
> Stefan Hajnoczi writes:
>
>> 4. Go and Rust bindings would also be useful. There is
>> https://github.com/intel/govmm but I think it makes sense to keep it
>> in qemu.git and provide an interface similar to our Python modules.
>
> Mapping QAPI/
On 12/23/19 2:38 PM, Paolo Bonzini wrote:
> On 23/12/19 12:40, Michal Prívozník wrote:
>>
>> diff --git i/target/i386/kvm.c w/target/i386/kvm.c
>> index 0b511906e3..7ee3202634 100644
>> --- i/target/i386/kvm.c
>> +++ w/target/i386/kvm.c
>> @@ -2173,6 +2173,7 @@ int kvm_arch_init(MachineState *ms, K
On Mon, Dec 23, 2019 at 02:37:58PM +0300, Denis Plotnikov wrote:
> Currenly, the virtqueue size is saved to the proxy on pci writing and
> is read from the device pci reading.
> The virtqueue size is propagated later on form the proxy to the device
> on virqueue enabling stage.
>
> This could be a
On Mon, Dec 23, 2019 at 12:02:18PM +0100, Paolo Bonzini wrote:
> On 23/12/19 10:18, Yang Zhong wrote:
> > In this time, the queue number in the front-end block driver is 2, but
> > the queue number in qemu side is still 4. So the guest virtio_blk
> > driver will failed to create vq with backe
On 2019/12/23 21:40, Vladimir Sementsov-Ogievskiy wrote:
> 23.12.2019 12:06, Eiichi Tsukata wrote:
>> bdrv_open_driver() allocates bs->opaque according to drv->instance_size.
>> There is no need to allocate it and overwrite opaque in
>> bdrv_backup_top_append().
>>
>> Reproducer:
>>
>>$ QTES
On 23/12/19 12:40, Michal Prívozník wrote:
>
> diff --git i/target/i386/kvm.c w/target/i386/kvm.c
> index 0b511906e3..7ee3202634 100644
> --- i/target/i386/kvm.c
> +++ w/target/i386/kvm.c
> @@ -2173,6 +2173,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
> }
>
> if (kvm_check_exte
1. virtqueue_size is a power of 2
2. virtqueue_size > 2, since seg_max is virtqueue_size - 2
Signed-off-by: Denis Plotnikov
---
hw/virtio/virtio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 04716b5f6c..e3ab69061e 100644
---
Hi!
20.12.2019, 19:09, "Markus Armbruster" :
> Yury Kotov writes:
>
>> Hi,
>>
>> This series is continuation of another one:
>> [PATCH] monitor: Fix slow reading
>> https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg03722.html
>>
>> Which also tried to read more than one byte from a st
23.12.2019 12:06, Eiichi Tsukata wrote:
> bdrv_open_driver() allocates bs->opaque according to drv->instance_size.
> There is no need to allocate it and overwrite opaque in
> bdrv_backup_top_append().
>
> Reproducer:
>
>$ QTEST_QEMU_BINARY=./x86_64-softmmu/qemu-system-x86_64 valgrind -q
> --
23.12.2019 11:39, Paolo Bonzini wrote:
> On 23/12/19 08:43, Vladimir Sementsov-Ogievskiy wrote:
>> diff --git a/vl.c b/vl.c
>> index 86474a55c9..9fb859969c 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -2779,7 +2779,7 @@ static void configure_accelerators(const char
>> *progname)
>> for (tmp
On 12/23/19 12:33 PM, Daniel P. Berrangé wrote:
> On Mon, Dec 23, 2019 at 12:28:43PM +0100, Michal Prívozník wrote:
>> On 12/18/19 1:02 PM, Paolo Bonzini wrote:
>>> Add it to microvm as well, it is a generic property of the x86
>>> architecture.
>>>
>>> Suggested-by: Sergio Lopez
>>> Signed-off-by
Currenly, the virtqueue size is saved to the proxy on pci writing and
is read from the device pci reading.
The virtqueue size is propagated later on form the proxy to the device
on virqueue enabling stage.
This could be a problem, if a guest, on the virtqueue configuration, sets
the size and then
On Mon, Dec 23, 2019 at 12:28:43PM +0100, Michal Prívozník wrote:
> On 12/18/19 1:02 PM, Paolo Bonzini wrote:
> > Add it to microvm as well, it is a generic property of the x86
> > architecture.
> >
> > Suggested-by: Sergio Lopez
> > Signed-off-by: Paolo Bonzini
> > ---
> > hw/i386/pc.c
On 12/18/19 1:02 PM, Paolo Bonzini wrote:
> Add it to microvm as well, it is a generic property of the x86
> architecture.
>
> Suggested-by: Sergio Lopez
> Signed-off-by: Paolo Bonzini
> ---
> hw/i386/pc.c | 49 -
> hw/i386/pc_piix.c
On 23/12/19 10:18, Yang Zhong wrote:
> In this time, the queue number in the front-end block driver is 2, but
> the queue number in qemu side is still 4. So the guest virtio_blk
> driver will failed to create vq with backend.
Where?
> There is no "set back"
> mechnism for block driver t
On Fri, 20 Dec 2019 17:49:34 +0800
Jiajun Chen wrote:
> There is a possible memory leak while local_link return -1 without free
> odirpath and oname.
>
> Reported-by: Euler Robot
> Signed-off-by: Jaijun Chen
> Signed-off-by: Xiang Zheng
> ---
Applied to 9p-next.
Thanks.
> hw/9pfs/9p-local
Eduardo Habkost wrote:
> On Fri, Dec 20, 2019 at 07:59:28PM +0100, Juan Quintela wrote:
>> Eduardo Habkost wrote:
>> > Python 3.5 is the oldest Python version available on our
>> > supported build platforms, and Python 2 end of life will be 3
>> > weeks after the planned release date of QEMU 4.2.
From: Pavel Dovgalyuk
This patch adds support of the reverse continue operation for gdbstub.
Reverse continue finds the last breakpoint that would happen in normal
execution from the beginning to the current moment.
Implementation of the reverse continue replays the execution twice:
to find the b
From: Pavel Dovgalyuk
Non-empty record/replay queue prevents saving and loading the VM state,
because it includes pending bottom halves and block coroutines.
But when the new VM state is loaded, we don't have to preserve the consistency
of the current state anymore. Therefore this patch just flus
From: Pavel Dovgalyuk
GDB remote protocol supports two reverse debugging commands:
reverse step and reverse continue.
This patch adds support of the first one to the gdbstub.
Reverse step is intended to step one instruction in the backwards
direction. This is not possible in regular execution.
Bu
From: Pavel Dovgalyuk
This patch updates the documentation and describes usage of the reverse
debugging in QEMU+GDB.
Signed-off-by: Pavel Dovgalyuk
---
docs/replay.txt | 33 +
1 file changed, 33 insertions(+)
diff --git a/docs/replay.txt b/docs/replay.txt
ind
From: Pavel Dovgalyuk
This patch adds hmp/qmp commands replay_seek/replay-seek that proceed
the execution to the specified instruction count.
The command automatically loads nearest snapshot and replays the execution
to find the desired instruction count.
Signed-off-by: Pavel Dovgalyuk
Acked-by
From: Pavel Dovgalyuk
This patch adds replay.json file. It will be
used for adding record/replay-related data structures and commands.
Signed-off-by: Pavel Dovgalyuk
Reviewed-by: Markus Armbruster
--
v10:
- minor changes
v13:
- rebased to the new QAPI files
---
MAINTAINERS |
From: Pavel Dovgalyuk
Saving icount as a parameters of the snapshot allows navigation between
them in the execution replay scenario.
This information can be used for finding a specific snapshot for proceeding
the recorded execution to the specific moment of the time.
E.g., 'reverse step' action (
From: Pavel Dovgalyuk
This patch introduces 'info replay' monitor command and
corresponding qmp request.
These commands request the current record/replay mode, replay log file
name, and the instruction count (number of recorded/replayed
instructions). The instruction count can be used with the
r
From: Pavel Dovgalyuk
This patch introduces replay_break, replay_delete_break
qmp and hmp commands.
These commands allow stopping at the specified instruction.
It may be useful for debugging when there are some known
events that should be investigated.
replay_break command has one argument - numb
From: Pavel Dovgalyuk
This patch introduces the icount field for saving within the snapshot.
It is required for navigation between the snapshots in record/replay mode.
Signed-off-by: Pavel Dovgalyuk
Acked-by: Kevin Wolf
--
v2:
- documented format changes in docs/interop/qcow2.txt
(sugges
1 - 100 of 119 matches
Mail list logo
