Since this one is intended to be a user-facing error message
rather than just a debug note, it could also be reasonably
expanded to be a bit more user friendly.
Reported-by: Peter Maydell
Signed-off-by: Mao Zhongyi
---
hw/i386/multiboot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
The new migration test uncovered some alignment problems in the s390x
code:
https://lists.gnu.org/archive/html/qemu-devel/2018-09/msg03012.html
Here are some patches to fix these issues (only tested with
clang and -fsanitize=undefined, since I do not have access to
a Sparc machine, but I hope tha
The IplParameterBlock and QemuIplParameters structures are declared
with QEMU_PACKED, so the compiler assumes that the structures do not
need to be aligned in memory. Since the are listed after a "bool"
within the S390IPLState, the IplParameterBlock and QemuIplParameters
are also indeed mis-aligned
The uint16_t member cu_type of struct SenseId is not naturally aligned,
and since the struct is marked with QEMU_PACKED, this can lead to
unaligned memory accesses - which does not work on architectures like
Sparc. Thus remove the QEMU_PACKED here and rather copy the struct
byte by byte when we do
struct SubchDev embeds several other structures which are marked with
QEMU_PACKED. This causes the compiler to not care for proper alignment
of these structures. When we later pass around pointers to the unaligned
struct members during migration, this causes problems on host architectures
like Spar
On 25/09/2018 22:17, Alex Bennée wrote:
>
> Marc-André Lureau writes:
>
>> Spotted by ASAN:
>>
>> QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/bios-tables-test
>> -p /x86_64/acpi/piix4/cpuhp
>> /x86_64/acpi/piix4/cpuhp: Could not access KVM kernel module: No such file
>> or direc
On 26/09/2018 07:44, Fam Zheng wrote:
>
> The dead loop happens immediately when the kernel boots and initializes
> the device, where virtio_scsi_data_plane_handle_cmd will not return:
>
> > ...
> > #13 0x5586602b7793 in virtio_scsi_handle_cmd_vq
> > #14 0x5586602b8d66 in virt
On 26/09/2018 09:38, Thomas Huth wrote:
> The IplParameterBlock and QemuIplParameters structures are declared
> with QEMU_PACKED, so the compiler assumes that the structures do not
> need to be aligned in memory. Since the are listed after a "bool"
> within the S390IPLState, the IplParameterBlock a
On 26/09/2018 09:38, Thomas Huth wrote:
> The uint16_t member cu_type of struct SenseId is not naturally aligned,
> and since the struct is marked with QEMU_PACKED, this can lead to
> unaligned memory accesses - which does not work on architectures like
> Sparc. Thus remove the QEMU_PACKED here and
On 2018-09-26 09:56, David Hildenbrand wrote:
> On 26/09/2018 09:38, Thomas Huth wrote:
>> The IplParameterBlock and QemuIplParameters structures are declared
>> with QEMU_PACKED, so the compiler assumes that the structures do not
>> need to be aligned in memory. Since the are listed after a "bool"
On 26/09/2018 10:04, David Hildenbrand wrote:
> On 26/09/2018 09:38, Thomas Huth wrote:
>> The uint16_t member cu_type of struct SenseId is not naturally aligned,
>> and since the struct is marked with QEMU_PACKED, this can lead to
>> unaligned memory accesses - which does not work on architectures
On 2018-09-26 10:04, David Hildenbrand wrote:
> On 26/09/2018 09:38, Thomas Huth wrote:
>> The uint16_t member cu_type of struct SenseId is not naturally aligned,
>> and since the struct is marked with QEMU_PACKED, this can lead to
>> unaligned memory accesses - which does not work on architectures
On 2018-09-26 10:07, David Hildenbrand wrote:
> On 26/09/2018 10:04, David Hildenbrand wrote:
>> On 26/09/2018 09:38, Thomas Huth wrote:
>>> The uint16_t member cu_type of struct SenseId is not naturally aligned,
>>> and since the struct is marked with QEMU_PACKED, this can lead to
>>> unaligned me
On Tue, 08/21 12:07, Marc-André Lureau wrote:
> -object iothread,id=foo,? will crash qemu:
>
> qemu-system-x86_64:qemu-thread-posix.c:128: qemu_cond_destroy: Assertion
> `cond->initialized' failed.
>
> Use thread_id != -1 to check if iothread_complete() finished
> successfully and the mutex/cond
On 26/09/2018 10:09, Thomas Huth wrote:
> On 2018-09-26 10:07, David Hildenbrand wrote:
>> On 26/09/2018 10:04, David Hildenbrand wrote:
>>> On 26/09/2018 09:38, Thomas Huth wrote:
The uint16_t member cu_type of struct SenseId is not naturally aligned,
and since the struct is marked with
Hi Paolo,
On Tue, Sep 25, 2018 at 11:26:36AM +0200, Paolo Bonzini wrote:
> Hi Samuel!
>
> On 25/09/2018 10:30, Thomas Huth wrote:
> > On 2018-09-24 11:21, Samuel Ortiz wrote:
> >> - Are there any fundamental reasons why the QEMU maintainers think that
> >> Kconfig would not fit QEMU's configura
On Tue, 25 Sep 2018 17:10:43 +0200
David Hildenbrand wrote:
> On 25/09/2018 16:19, Igor Mammedov wrote:
> > On Thu, 20 Sep 2018 12:32:27 +0200
> > David Hildenbrand wrote:
> >
> >> Document the functions and when to not expect errors.
> >>
> >> Signed-off-by: David Hildenbrand
> >> ---
> >>
On Tue, 25 Sep 2018 22:03:06 +0200
David Hildenbrand wrote:
> On 24/09/2018 15:54, Igor Mammedov wrote:
> > On Thu, 20 Sep 2018 12:32:35 +0200
> > David Hildenbrand wrote:
> >
> >> Let's trace the address when pre_pluggin/plugging/unplugging a memory
> >> device.
> >>
> >> Trace it when pre_
On 25 September 2018 at 10:26, Paolo Bonzini wrote:
> However, the Kconfig language is a good idea. The idea is that
> dependencies can be expressed:
>
> - as "select" whenever a board requires a device, or whenever a device
> requires generic subsystem code in order to implement a controller for
Hi
On Wed, Sep 26, 2018 at 12:13 PM Fam Zheng wrote:
>
> On Tue, 08/21 12:07, Marc-André Lureau wrote:
> > -object iothread,id=foo,? will crash qemu:
> >
> > qemu-system-x86_64:qemu-thread-posix.c:128: qemu_cond_destroy: Assertion
> > `cond->initialized' failed.
> >
> > Use thread_id != -1 to ch
On 2018-09-26 10:17, David Hildenbrand wrote:
> On 26/09/2018 10:09, Thomas Huth wrote:
>> On 2018-09-26 10:07, David Hildenbrand wrote:
>>> On 26/09/2018 10:04, David Hildenbrand wrote:
On 26/09/2018 09:38, Thomas Huth wrote:
> The uint16_t member cu_type of struct SenseId is not naturall
On Fri, Sep 21, 2018 at 08:59:07AM +0200, Roman Kapl wrote:
> External PID is a mechanism present on BookE 2.06 that enables application to
> store/load data from different address spaces. There are special version of
> some
> instructions, which operate on alternate address space, which is specif
On 26/09/2018 10:36, Thomas Huth wrote:
> On 2018-09-26 10:17, David Hildenbrand wrote:
>> On 26/09/2018 10:09, Thomas Huth wrote:
>>> On 2018-09-26 10:07, David Hildenbrand wrote:
On 26/09/2018 10:04, David Hildenbrand wrote:
> On 26/09/2018 09:38, Thomas Huth wrote:
>> The uint16_t m
On 26/09/2018 10:29, Igor Mammedov wrote:
> On Tue, 25 Sep 2018 17:10:43 +0200
> David Hildenbrand wrote:
>
>> On 25/09/2018 16:19, Igor Mammedov wrote:
>>> On Thu, 20 Sep 2018 12:32:27 +0200
>>> David Hildenbrand wrote:
>>>
Document the functions and when to not expect errors.
On Wed, 26 Sep 2018 10:43:09 +0200
David Hildenbrand wrote:
> On 26/09/2018 10:36, Thomas Huth wrote:
> > On 2018-09-26 10:17, David Hildenbrand wrote:
> >> On 26/09/2018 10:09, Thomas Huth wrote:
> >>> On 2018-09-26 10:07, David Hildenbrand wrote:
> On 26/09/2018 10:04, David Hildenbr
Device models aren't supposed to go on fishing expeditions for
backends. They should expose suitable properties for the user to set.
For onboard devices, board code sets them.
Device ssi-sd picks up its block backend in its init() method with
drive_get_next() instead. This mistake is already mar
On 2018-09-26 10:43, David Hildenbrand wrote:
> On 26/09/2018 10:36, Thomas Huth wrote:
>> On 2018-09-26 10:17, David Hildenbrand wrote:
>>> On 26/09/2018 10:09, Thomas Huth wrote:
On 2018-09-26 10:07, David Hildenbrand wrote:
> On 26/09/2018 10:04, David Hildenbrand wrote:
>> On 26/09
On Wed, 09/26 12:33, Marc-André Lureau wrote:
> Hi
>
> On Wed, Sep 26, 2018 at 12:13 PM Fam Zheng wrote:
> >
> > On Tue, 08/21 12:07, Marc-André Lureau wrote:
> > > -object iothread,id=foo,? will crash qemu:
> > >
> > > qemu-system-x86_64:qemu-thread-posix.c:128: qemu_cond_destroy: Assertion
> >
On 26/09/2018 11:09, Thomas Huth wrote:
> On 2018-09-26 10:43, David Hildenbrand wrote:
>> On 26/09/2018 10:36, Thomas Huth wrote:
>>> On 2018-09-26 10:17, David Hildenbrand wrote:
On 26/09/2018 10:09, Thomas Huth wrote:
> On 2018-09-26 10:07, David Hildenbrand wrote:
>> On 26/09/2018
On 2018-09-26 11:00, Markus Armbruster wrote:
> Device models aren't supposed to go on fishing expeditions for
> backends. They should expose suitable properties for the user to set.
> For onboard devices, board code sets them.
>
> Device ssi-sd picks up its block backend in its init() method wit
Am 25.09.2018 um 07:05 hat Fam Zheng geschrieben:
> Image locking errors happening at device initialization time doesn't say
> which file cannot be locked, for instance,
>
> -device scsi-disk,drive=drive-1: Failed to get shared "write" lock
> Is another process using the image?
>
> could
We're missing "x" after the leading 0.
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/mem/memory-device.c b/hw/mem/memory-device.c
index 6de4f70bb4..0b52fe2c5e 100644
--- a/hw/mem/memory-device.c
+++ b/hw/mem/mem
On Wed, 26 Sep 2018 09:38:45 +0200
Thomas Huth wrote:
> The IplParameterBlock and QemuIplParameters structures are declared
> with QEMU_PACKED, so the compiler assumes that the structures do not
> need to be aligned in memory. Since the are listed after a "bool"
> within the S390IPLState, the Ipl
The "at" should actually be a "before".
if (new_addr < address_space_start)
-> "can't add memory ... before... $address_space_start"
So it looks similar to the other check
} else if ((new_addr + size) > address_space_end)
-> "can't add memory ... beyond..."
Reviewed-by: Dr. Davi
Some architectures might support memory devices, while they don't
support DIMM/NVDIMM. So let's
- Rename CONFIG_MEM_HOTPLUG to CONFIG_MEM_DEVICE
- Introduce CONFIG_DIMM and use it similarly to CONFIG NVDIMM
CONFIG_DIMM and CONFIG_NVDIMM require CONFIG_MEM_DEVICE.
Reviewed-by: Igor Mammedov
Revie
This series completes refactoring of pre_plug, plug and unplug logic of
memory devices. With this as a basis, one can easily have e.g. virtio
based memory devices (virtio-mem, virtio-pmem, virtio-fs?) with minor
modifications on e.g. x86.
Patch 1-18 are the "real" patches of this series. Patch 19-
Although unlikely in practice, we could have integer overflows on some
calculations based on addresses and sizes, leading to error checks not
triggering.
Let's properly handle this whenever we do an addition. Make
address_space_end point at the real end, instead of end + 1, so we don't
have to han
We're plugging/unplugging a PCDIMMDevice, so directly pass this type
instead of a more generic DeviceState.
Signed-off-by: David Hildenbrand
---
hw/i386/pc.c | 6 +++---
hw/mem/pc-dimm.c | 16 +++-
hw/ppc/spapr.c | 8
include/hw/mem/pc-dimm.h
We will factor out get_memory_region() from pc-dimm to memory device code
soon. Once that is done, get_region_size() can be implemented
generically and essentially be replaced by
memory_device_get_region_size (and work only on get_memory_region()).
We have some users of get_memory_region() (spapr
While we rephrased most error messages, we missed these.
Reviewed-by: Dr. David Alan Gilbert
Reviewed-by: Igor Mammedov
Reviewed-by: David Gibson
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/mem/memory
With the new memory device functions in place, we can factor out
plugging of memory devices completely.
Reviewed-by: David Gibson
Reviewed-by: Igor Mammedov
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 13 ++---
hw/mem/pc-dimm.c | 9 +
in
The memory region is necessary for plugging/unplugging a memory device.
The region size (via get_region_size()) is no longer sufficient, as
besides the alignment, also the region itself is required in order to
add it to the device memory region of the machine via
- memory_region_add_subregion
- mem
Document the functions and when to not expect errors.
Reviewed-by: David Gibson
Signed-off-by: David Hildenbrand
---
include/hw/mem/memory-device.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/hw/mem/memory-device.h b/include/hw/mem/memory-device.h
index f02b229
With the new memory device functions in place, we can factor out
unplugging of memory devices completely.
Reviewed-by: David Gibson
Reviewed-by: Igor Mammedov
Signed-off-by: David Hildenbrand
---
hw/mem/memory-device.c | 11 +--
hw/mem/pc-dimm.c | 5 +
includ
Let's properly forward the errors, so errors from get_region_size() /
get_plugged_size() can be handled.
Users right now call both functions after the device has been realized,
which is will never fail, so it is fine to continue using error_abort.
While at it, remove a leftover error check (sugge
virtio-pmem devices will have to be hotplugged using the machine hotplug
handler just like other memory devices. Therefore, all machines that
want to support virtio-pmem will have to modify their machine hotplug
handler.
virtio-pmem devices are realized when their parent proxy device
(virtio-pmem-
Let's trace the address when pre_pluggin/plugging/unplugging a memory device.
Trace it when pre_plugging as well as when plugging, so we really know
when a specific address is actually used.
Reviewed-by: David Gibson
Reviewed-by: Igor Mammedov
Signed-off-by: David Hildenbrand
---
hw/mem/memor
There are no remaining users of get_region_size() except
memory_device_get_region_size() itself. We can make
memory_device_get_region_size() work directly on get_memory_region()
instead and drop get_region_size().
In addition, we can now use memory_device_get_region_size() in pc-dimm
code to imple
When reporting the id of virtio-based memory devices, we always have to
take the one of the proxy device (parent), not the one of the memory
device directly.
Let's generalize this by allowing memory devices to specify an optional
"get_device_id" function. This id can then be used to report errors
From: Pankaj Gupta
We need a proxy device for virtio-pmem.
Reviewed-by: David Gibson
Signed-off-by: Pankaj Gupta
[ split up patches ]
Signed-off-by: David Hildenbrand
---
hw/virtio/virtio-pci.c | 41 +
hw/virtio/virtio-pci.h | 14 ++
includ
To be able to factor out address asignment of memory devices, we will
have to read (get_addr()) and write (set_addr()) the address.
We can't use properties for this purpose, as properties are device
specific. E.g. while the address property for a DIMM is called "addr", it
might be called different
Print the memory device info just like for PCDIMM/NVDIMM.
Signed-off-by: David Hildenbrand
---
hmp.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/hmp.c b/hmp.c
index 3a9f797677..159f82e155 100644
--- a/hmp.c
+++ b/hmp.c
@@ -2532,6 +2532,7 @@ v
On 9/21/18 5:37 PM, Peter Maydell wrote:
> On 21 September 2018 at 06:39, Damien Hedde
> wrote:
>> On 09/19/2018 11:30 PM, Peter Maydell wrote:
>>> There are several possible approaches here I think:
>>>
>>> (1) the "clock" object holds no internal state; if a device on the
>>> destination en
With all required memory device class functions in place, we can factor
out pre_plug handling of memory devices. Take proper care of errors. We
still have to carry along legacy_align required for pc compatibility
handling.
We will factor out tracing of the address separately in a follow-up
patch.
On 2018-09-26 11:42, Cornelia Huck wrote:
> On Wed, 26 Sep 2018 09:38:45 +0200
> Thomas Huth wrote:
>
>> The IplParameterBlock and QemuIplParameters structures are declared
>> with QEMU_PACKED, so the compiler assumes that the structures do not
>> need to be aligned in memory. Since the are liste
Account the memory to node 0 for now. Once (if ever) virtio-pmem
supports NUMA, we can account it to the right node.
Signed-off-by: David Hildenbrand
---
numa.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/numa.c b/numa.c
index 81542d4ebb..1ff141
The unplug and unplug_request handlers are special: They are not
executed when unrealizing a device, but rather trigger the removal of a
device from device_del() via object_unparent() - to effectively
unrealize a device.
If such a device has a child bus and another device attached to
that bus (e.g
Hi,
This idea comes from BiteSizedTasks, and this patch series implement
the error checking of qemu_thread_create: make qemu_thread_create
return a flag to indicate if it succeeded rather than failing with an
error; make all callers check it.
The first three patches apply to those call traces who
To avoid the segmentation fault in qemu_thread_join(), just directly
return when the QemuThread *thread failed to be created in either
qemu-thread-posix.c or qemu-thread-win32.c.
Signed-off-by: Fei Li
Reviewed-by: Fam Zheng
---
util/qemu-thread-posix.c | 3 +++
util/qemu-thread-win32.c | 2 +-
On Wed, 26 Sep 2018 09:38:46 +0200
Thomas Huth wrote:
> The uint16_t member cu_type of struct SenseId is not naturally aligned,
> and since the struct is marked with QEMU_PACKED, this can lead to
> unaligned memory accesses - which does not work on architectures like
> Sparc. Thus remove the QEMU
From: Pankaj Gupta
This is the current protoype of virtio-pmem. Support will require
machine changes for the architectures that will support it, so it will
not yet be compiled.
Signed-off-by: Pankaj Gupta
[ MemoryDevice/MemoryRegion changes, cleanups, addr property "memaddr",
split up patches
When multifd is used during migration, if there is an error before
the destination receives all new channels, the destination does not
exit but keeps waiting in our current code. However, a segmentaion
fault will occur in the source when multifd_save_cleanup() is called
again as the multifd_send_st
The caller of qemu_init_vcpu() already passed the **errp to handle
errors. In view of this, add a new Error parameter to the following
call trace to propagate the error and let the further caller check it.
Besides, make qemu_init_vcpu() return a Boolean value to let its
callers know whether it suc
Compile virtio-pmem for x86 and properly hotplug virtio-pmem devices
(memory-device part) from our pc machine hotplug handler.
Signed-off-by: David Hildenbrand
---
default-configs/i386-softmmu.mak | 1 +
hw/i386/pc.c | 17 -
2 files changed, 17 insertions(+),
On 2018-09-26 11:55, Cornelia Huck wrote:
> On Wed, 26 Sep 2018 11:46:22 +0200
> Thomas Huth wrote:
>
>> On 2018-09-26 11:42, Cornelia Huck wrote:
>>> On Wed, 26 Sep 2018 09:38:45 +0200
>>> Thomas Huth wrote:
>>>
The IplParameterBlock and QemuIplParameters structures are declared
wi
Add error handling for qemu_ram_foreach_migratable_block() when
it fails.
Always call migrate_set_error() to set the error state without relying
on whether multifd_save_cleanup() succeeds. As the passed &local_err
is never used in multifd_save_cleanup(), remove it.
Signed-off-by: Fei Li
---
mig
On Wed, 26 Sep 2018 11:46:22 +0200
Thomas Huth wrote:
> On 2018-09-26 11:42, Cornelia Huck wrote:
> > On Wed, 26 Sep 2018 09:38:45 +0200
> > Thomas Huth wrote:
> >
> >> The IplParameterBlock and QemuIplParameters structures are declared
> >> with QEMU_PACKED, so the compiler assumes that the
On 2018-09-26 11:53, Cornelia Huck wrote:
> On Wed, 26 Sep 2018 09:38:46 +0200
> Thomas Huth wrote:
>
>> The uint16_t member cu_type of struct SenseId is not naturally aligned,
>> and since the struct is marked with QEMU_PACKED, this can lead to
>> unaligned memory accesses - which does not work
Hi Markus,
On 9/26/18 11:00 AM, Markus Armbruster wrote:
> Device models aren't supposed to go on fishing expeditions for
> backends. They should expose suitable properties for the user to set.
> For onboard devices, board code sets them.
>
> Device ssi-sd picks up its block backend in its init(
On Wed, 09/26 18:02, Fei Li wrote:
> Currently, when qemu_signal_init() fails it only returns a non-zero
> value but without propagating any Error. But its callers need a
> non-null err when runs error_report_err(err), or else 0->msg occurs.
>
> To avoid such segmentation fault, add a new Error pa
Add a new Error parameter for vnc_display_init() to handle errors
in its caller: vnc_init_func(), just like vnc_display_open() does.
And let the call trace propagate the Error.
Besides, make vnc_start_worker_thread() return a bool to indicate
whether it succeeds instead of returning nothing.
Sign
Currently, when qemu_signal_init() fails it only returns a non-zero
value but without propagating any Error. But its callers need a
non-null err when runs error_report_err(err), or else 0->msg occurs.
To avoid such segmentation fault, add a new Error parameter to make
the call trace to propagate t
Make qemu_thread_create() return a Boolean to indicate if it succeeds
rather than failing with an error. And add an Error parameter to hold
the error message and let the callers handle it.
Signed-off-by: Fei Li
---
cpus.c | 45 +++--
dump.
On Wed, 09/26 18:02, Fei Li wrote:
> diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
> index 289af4fab5..8b044e2798 100644
> --- a/util/qemu-thread-posix.c
> +++ b/util/qemu-thread-posix.c
> @@ -15,6 +15,7 @@
> #include "qemu/atomic.h"
> #include "qemu/notify.h"
> #include "qemu
Hi Peter,
On 9/25/18 4:41 PM, Peter Maydell wrote:
> In commit c79c0a314c43b78 we enabled emulation of external aborts
> when the guest attempts to access a physical address with no
> mapped device. In commit 4672cbd7bed88dc6 we suppress this for
> most legacy boards to prevent breakage of previou
Am 25.09.2018 um 00:53 hat Leonid Bloch geschrieben:
> The caches are now recalculated upon image resizing. This is done
> because the new default behavior of assigning L2 cache relatively to
> the image size, implies that the cache will be adapted accordingly
> after an image resize.
>
> Signed-o
Am 25.09.2018 um 00:53 hat Leonid Bloch geschrieben:
> This series makes the qcow2 L2 cache assignment aware of the image size,
> with the intention for it to cover the entire image. The importance of
> this change is in noticeable performance improvement, especially with
> heavy random I/O. The me
On Wed 26 Sep 2018 12:43:03 PM CEST, Kevin Wolf wrote:
>> +/* Update cache sizes */
>> +options = qdict_clone_shallow(bs->options);
>> +ret = qcow2_update_options(bs, options, s->flags, errp);
>> +if (ret < 0) {
>> +goto fail;
>> +}
>
> Isn't options leaked, both in succ
On Wed 26 Sep 2018 12:48:18 PM CEST, Kevin Wolf wrote:
> By the way, Berto: While reviewing this, I noticed that we don't make
> use of the l2-cache-entry-size feature yet by default. I think you
> said you wanted to do some more tests to find a good default
> (intuitively, I'd expect it around MI
On 2018-09-17 11:34, David Hildenbrand wrote:
> Move it into TCG-only code and provide a stub. Turn it into noreturn.
>
> As Richard noted, we currently don't log the psw.addr before restoring
> the state, fix that by moving (duplicating) the qemu_log_mask in the
> tcg/kvm handlers.
>
> Reviewed-
Update: I do have changed all important vms to a fuserfs image mount.
The problem seems to occur when you write a lot of smaller files in a
short period of time on the VMs ext4 filesystem. The best way for me to
reproduce that is by doing an "apt upgrade" (see attachment)
This particular VM is co
On 09/25/18 22:36, Alex Williamson wrote:
> On Tue, 25 Sep 2018 00:13:46 +0200
> Laszlo Ersek wrote:
>
>> In commit 9fa99d2519cb ("hw/pci-host: Fix x86 Host Bridges 64bit PCI
>> hole", 2017-11-16), we meant to expose such a 64-bit PCI MMIO aperture in
>> the ACPI DSDT that would be at least as la
On 09/26/2018 06:36 PM, Fam Zheng wrote:
On Wed, 09/26 18:02, Fei Li wrote:
diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
index 289af4fab5..8b044e2798 100644
--- a/util/qemu-thread-posix.c
+++ b/util/qemu-thread-posix.c
@@ -15,6 +15,7 @@
#include "qemu/atomic.h"
#includ
Fix the assertion failure when running interrupts.
Signed-off-by: Alex Bennée
---
target/arm/kvm64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 80ad07ed0c..346e1f1a73 100644
--- a/target/arm/kvm64.c
+++ b/target/arm/kvm64.c
@@ -984,7 +984,
On 2018-09-26 13:21, David Hildenbrand wrote:
>
>>> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
>>> index 5a9fe45ce8..db378f6238 100644
>>> --- a/hw/s390x/css.c
>>> +++ b/hw/s390x/css.c
>>> @@ -750,12 +750,13 @@ static void sch_handle_halt_func(SubchDev *sch)
>>>
>>> }
>>>
>>> -static void copy_
This only fails with some (broken) versions of gdb but we should
treat the top bits of DBGBVR as RESS. As the hardware may have IMPDEF
approaches to writes to this register we apply the sign extension when
checking breakpoints.
Signed-off-by: Alex Bennée
---
target/arm/kvm64.c | 12 +++-
>> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
>> index 5a9fe45ce8..db378f6238 100644
>> --- a/hw/s390x/css.c
>> +++ b/hw/s390x/css.c
>> @@ -750,12 +750,13 @@ static void sch_handle_halt_func(SubchDev *sch)
>>
>> }
>>
>> -static void copy_sense_id_to_guest(SenseId *dest, SenseId *src)
>> +stati
Hi,
While at Connect I had a go at reproducing a problem that Ard had
reported to me about guest debug not working. I managed to replicate
it and uncovered a few other nits in the process. While upgrading to a
tip-of-tree gdb to get around:
https://sourceware.org/bugzilla/show_bug.cgi?id=23127
You should declare you are using a global version of a variable before
you attempt to modify it in a function.
Signed-off-by: Alex Bennée
---
tests/guest-debug/test-gdbstub.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/guest-debug/test-gdbstub.py
b/tests/guest-debug/test-gdbstub.
** Tags added: qemu
** Tags added: glusterfs
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1793904
Title:
files are randomly overwritten by Zero Bytes
Status in QEMU:
New
Bug description:
He
When we are debugging the guest all exception come our way but might
be for the guests own debug exceptions. We use the ->do_interrupt()
infrastructure to do this however we are missing a full setup of the
exception structure causing an assert later down the line.
Signed-off-by: Alex Bennée
---
Am 06.09.2018 um 11:37 hat Alberto Garcia geschrieben:
> 'force-share' is one of the basic BlockdevOptions available for all
> drivers, but it's not handled by bdrv_reopen_prepare() so any attempt
> to change it results in a "Cannot change the option" error:
>
>(qemu) qemu-io virtio0 "reopen -
On Wed 26 Sep 2018 01:34:28 PM CEST, Kevin Wolf wrote:
>> @@ -3353,6 +3370,7 @@ void bdrv_reopen_commit(BDRVReopenState *reopen_state)
>> bs->open_flags = reopen_state->flags;
>> bs->read_only = !(reopen_state->flags & BDRV_O_RDWR);
>> bs->detect_zeroes = reopen_state->d
20.06.2018 19:07, John Snow wrote:
On 06/20/2018 11:28 AM, Vladimir Sementsov-Ogievskiy wrote:
20.06.2018 18:27, Vladimir Sementsov-Ogievskiy wrote:
Libvirt part is ready, let's drop x- prefix.
libvirt patches will be sent soon I hope.
OK, can you ping this patch with a link to the series w
On 09/26/18 13:12, Laszlo Ersek wrote:
> (4) append a new patch, for "bios-tables-test", so that the ACPI gen
> change is validated as part of the test suite, on SeaBIOS/q35.
>
> Regarding (4):
>
> - is it OK if I add the test only for Q35?
>
> - what guest RAM size am I allowed to use in the t
Thomas Huth writes:
> On 2018-09-26 11:00, Markus Armbruster wrote:
>> Device models aren't supposed to go on fishing expeditions for
>> backends. They should expose suitable properties for the user to set.
>> For onboard devices, board code sets them.
>>
>> Device ssi-sd picks up its block bac
On 2018-09-17 11:34, David Hildenbrand wrote:
> The DXC is to be stored in the low core, and only in the FPC in case AFP
> is enabled in CR0. Stub is not required in current code, but this way
> we never run into problems.
>
> Reviewed-by: Richard Henderson
> Signed-off-by: David Hildenbrand
> -
Philippe Mathieu-Daudé writes:
> Hi Markus,
>
> On 9/26/18 11:00 AM, Markus Armbruster wrote:
>> Device models aren't supposed to go on fishing expeditions for
>> backends. They should expose suitable properties for the user to set.
>> For onboard devices, board code sets them.
>>
>> Device ssi
26.09.2018 02:49, John Snow wrote:
Instead of both frozen and qmp_locked checks, wrap it into one check.
frozen implies the bitmap is split in two (for backup), and shouldn't
be modified. qmp_locked implies it's being used by another operation,
like being exported over NBD. In both cases it means
26.09.2018 02:49, John Snow wrote:
We wish to prohibit merging to read-only bitmaps and frozen bitmaps,
but "disabled" bitmaps only preclude their recording of live, new
information. It does not prohibit them from manual writes at the behest
of the user, as is the case for merge operations.
Allo
1 - 100 of 277 matches
Mail list logo
