The aim of this patch is to move existing numa global have_numa_distance
into NumaState.
Suggested-by: Igor Mammedov
Suggested-by: Eduardo Habkost
Signed-off-by: Tao Xu
---
hw/arm/virt-acpi-build.c | 2 +-
hw/arm/virt.c| 1 +
hw/i386/acpi-build.c | 2 +-
include/hw/boards.h
The aim of this patch is to add struct NumaState in MachineState
and move existing numa global nb_numa_nodes into NumaState.
And add variable numa_support into MachineClass to decide which
submachines support NUMA.
Suggested-by: Igor Mammedov
Suggested-by: Eduardo Habkost
Signed-off-by: Tao Xu
The aim of this patch is to add struct NumaState in MachineState
and move existing numa global nb_numa_nodes into NumaState.
And add variable numa_support into MachineClass to decide which
submachines support NUMA.
---
Changes in v2:
- fix the mistake in numa_complete_configuration in numa.c
The aim of this patch is to move existing numa global numa_info
into NumaState.
Suggested-by: Igor Mammedov
Suggested-by: Eduardo Habkost
Signed-off-by: Tao Xu
---
exec.c | 2 +-
hw/acpi/aml-build.c | 6 --
hw/arm/boot.c| 2 +-
hw/arm/virt-acpi-build.c
Hello,
Thank you for the suggestions on this.
>
> > On Thu 11-04-19 07:51:48, Dan Williams wrote:
> >> On Tue, Apr 9, 2019 at 9:09 PM Pankaj Gupta wrote:
> >> > + } else {
> >> > + if (nd_region->flush(nd_region))
> >> > + rc = -EIO;
> >>
> >> Given
Eric Blake writes:
> On 4/17/19 2:18 PM, Markus Armbruster wrote:
>> INIT_DISASSEMBLE_INFO() takes an fprintf()-like callback and a FILE *
>> to pass to it. monitor_disas() passes monitor_fprintf() and the
>> current monitor cast to FILE *. monitor_fprintf() casts it right
>> back, and is other
Alex Williamson writes:
> On Wed, 17 Apr 2019 21:06:33 +0200
> Markus Armbruster wrote:
>
>> Cc: Alex Williamson
>> Signed-off-by: Markus Armbruster
>> ---
>> hw/vfio/pci.c | 19 +--
>> 1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/vfio/pci.c b/hw/vfi
** Changed in: qemu (Debian)
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/639651
Title:
DRIVER_IRQL_NOT_LESS_OR_EQUAL booting WIndows XP with Synaptics driver
in
Am 17.04.19 um 20:27 schrieb Laszlo Ersek:
So, let's look at your original question again (which was not a problem
statement):
So you need an explicit problem statement to know that somebody might
have a problem?
what's the reasoning behind "We need a terminal output" in curses.c?
The rea
On 18/04/2019 00.01, Stephen Checkoway wrote:
> During a sector erase (but not a chip erase), the embeded erase program
> can be suspended. Once suspended, the sectors not selected for erasure
> may be read and programmed. Autoselect mode is allowed during erase
> suspend mode. Presumably, CFI quer
On Tue, Apr 16, 2019 at 11:59:42PM -0300, Eduardo Habkost wrote:
> The return value of cpu_get_model() is just a CPU model name and
> never includes extra options. We don't need to call
> parse_cpu_option().
Oops. I was wrong. linux-user also supports extra features in
the "-cpu" option, so we
On 18/04/2019 00.01, Stephen Checkoway wrote:
> After two unlock cycles and a sector erase command, the AMD flash chips
> start a 50 us erase time out. Any additional sector erase commands add a
> sector to be erased and restart the 50 us timeout. During the timeout,
> status bit DQ3 is cleared. Af
On 18/04/2019 00.01, Stephen Checkoway wrote:
> Test the AMD command set for parallel flash chips. This test uses an
> ARM musicpal board with a pflash drive to test the following list of
> currently-supported commands.
> - Autoselect
> - CFI
> - Sector erase
> - Chip erase
> - Program
> - Unlock b
On Wed, Apr 17, 2019 at 01:31:43PM +0200, David Hildenbrand wrote:
> Rename qemu_getrampagesize() to qemu_minrampagesize(). While at it,
> properly rename find_max_supported_pagesize() to
> find_min_backend_pagesize().
>
> s390x is actually interested into the maximum ram pagesize, so
> introduce
On 18/04/2019 00.01, Stephen Checkoway wrote:
> After a flash device enters CFI mode from autoselect mode, the reset
> command returns the device to autoselect mode. An additional reset
> command is necessary to return to read array mode.
>
> Signed-off-by: Stephen Checkoway
> ---
[...]
> diff --
On 18/04/2019 00.01, Stephen Checkoway wrote:
> Some flash chips support sectors of different sizes. For example, the
> AMD AM29LV160DT has 31 64 kB sectors, one 32 kB sector, two 8 kB
> sectors, and a 16 kB sector, in that order. The AM29LV160DB has those in
> the reverse order.
>
> The `num-bloc
On 18/04/2019 00.01, Stephen Checkoway wrote:
> It's common for multiple narrow flash chips to be hooked up in parallel
> to support wider buses. For example, four 8-bit wide flash chips (x8)
> may be combined in parallel to produce a 32-bit wide device. Similarly,
> two 16-bit wide chips (x16) may
On 18/04/2019 00.01, Stephen Checkoway wrote:
> Most AMD commands only examine 11 bits of the address. This masks the
> addresses used in the comparison to 11 bits. The exceptions are word or
> sector addresses which use offset directly rather than the shifted
> offset, boff.
>
> Signed-off-by: St
Hi,
I was trying to migrate a VM(CentOS7) which started with 4G memory and hot
plugged 5 memslots with 1G each. So the VM has total of 9G memory and
trying to migrate fails in vhost_dev_init() on destination host
if (used_memslots >
hdev->vhost_ops->vhost_backend_memslots_limit(hdev)) {
Following the previous patch, this patch adds peripheral devices to the
newly introduced SBSA-ref machine.
Signed-off-by: Hongbo Zhang
---
hw/arm/sbsa-ref.c | 451 ++
1 file changed, 451 insertions(+)
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sb
For the Aarch64, there is one machine 'virt', it is primarily meant to
run on KVM and execute virtualization workloads, but we need an
environment as faithful as possible to physical hardware, for supporting
firmware and OS development for pysical Aarch64 machines.
This patch introduces new machin
For the Aarch64, there is one machine 'virt', it is primarily meant to
run on KVM and execute virtualization workloads, but we need an
environment as faithful as possible to physical hardware, to support
firmware and OS development for pysical Aarch64 machines.
This machine comes with:
- Re-desi
hppa_cpu_list() is dead code and is never called. Delete it.
Cc: Richard Henderson
Signed-off-by: Eduardo Habkost
---
target/hppa/cpu.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/target/hppa/cpu.c b/target/hppa/cpu.c
index 00bf444620..b3b1826209 100644
--- a/tar
Fix the following crash:
$ qemu-system-x86_64 -cpu ''
qemu-system-x86_64: qom/cpu.c:291: cpu_class_by_name: \
Assertion `cpu_model && cc->class_by_name' failed.
Regression test script included.
Fixes: commit 99193d8f2ef5 ("cpu: drop unnecessary NULL check and
cpu_common_class_by_name(
On Wed, Apr 17, 2019 at 07:45:24AM +0200, Markus Armbruster wrote:
> Eduardo Habkost writes:
>
> > My initial goal was simple: removing the qdev_get_machine() call
> > from ppc_cpu_parse_featurestr() because I want to make
> > qdev_get_machine() available only to softmmu code.
> >
> > Before doin
Sounds good, let's keep in touch. __
Thanks,
Wei
On 4/17/19, 5:17 AM, "Paolo Bonzini" wrote:
On 17/04/19 03:38, Wei Li wrote:
> Thanks Paolo for your response and clarification.
>
> Btw, is there any rough schedule about when are you planning to start
> working on the mult
David Gibson's on April 17, 2019 10:47 pm:
> On Wed, Apr 17, 2019 at 02:01:29PM +0200, Greg Kurz wrote:
>> On Wed, 17 Apr 2019 21:20:00 +1000
>> Nicholas Piggin wrote:
>> > [...]
>> > >> @@ -1860,6 +1928,9 @@ static void hypercall_register_types(void)
>> > >> /* hcall-splpar */
>> > >> s
Greg Kurz's on April 17, 2019 10:01 pm:
> On Wed, 17 Apr 2019 21:20:00 +1000
> Nicholas Piggin wrote:
>> [...]
>> >> @@ -1860,6 +1928,9 @@ static void hypercall_register_types(void)
>> >> /* hcall-splpar */
>> >> spapr_register_hypercall(H_REGISTER_VPA, h_register_vpa);
>> >> spapr_
This just about rewrites the entirety of the bitmaps.rst document to
make it consistent with the 4.0 release. I have added new features seen
in the 4.0 release, as well as tried to clarify some points that keep
coming up when discussing this feature both in-house and upstream.
Yes, it's a lot long
On Wed, 17 Apr 2019 21:06:33 +0200
Markus Armbruster wrote:
> Cc: Alex Williamson
> Signed-off-by: Markus Armbruster
> ---
> hw/vfio/pci.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 504019c458..0142819ea6
When the flash device is performing a chip erase, all commands are
ignored. When it is performing a sector erase, only the erase suspend
command is valid, which is currently not supported.
In particular, the reset command should not cause the device to reset to
read array mode while programming is
It's common for multiple narrow flash chips to be hooked up in parallel
to support wider buses. For example, four 8-bit wide flash chips (x8)
may be combined in parallel to produce a 32-bit wide device. Similarly,
two 16-bit wide chips (x16) may be combined.
This commit introduces `device-width` a
Most AMD commands only examine 11 bits of the address. This masks the
addresses used in the comparison to 11 bits. The exceptions are word or
sector addresses which use offset directly rather than the shifted
offset, boff.
Signed-off-by: Stephen Checkoway
---
hw/block/pflash_cfi02.c | 8 +
After two unlock cycles and a sector erase command, the AMD flash chips
start a 50 us erase time out. Any additional sector erase commands add a
sector to be erased and restart the 50 us timeout. During the timeout,
status bit DQ3 is cleared. After the time out, DQ3 is asserted during
erasure.
Sig
During a sector erase (but not a chip erase), the embeded erase program
can be suspended. Once suspended, the sectors not selected for erasure
may be read and programmed. Autoselect mode is allowed during erase
suspend mode. Presumably, CFI queries are similarly allowed so this
commit allows them a
When erasing the chip, use the typical time specified in the CFI table
rather than arbitrarily selecting 5 seconds.
Since the currently unconfigurable value set in the table is 12, this
means a chip erase takes 4096 ms so this isn't a big change in behavior.
Signed-off-by: Stephen Checkoway
---
Test the AMD command set for parallel flash chips. This test uses an
ARM musicpal board with a pflash drive to test the following list of
currently-supported commands.
- Autoselect
- CFI
- Sector erase
- Chip erase
- Program
- Unlock bypass
- Reset
Signed-off-by: Stephen Checkoway
---
tests/Make
Some flash chips support sectors of different sizes. For example, the
AMD AM29LV160DT has 31 64 kB sectors, one 32 kB sector, two 8 kB
sectors, and a 16 kB sector, in that order. The AM29LV160DB has those in
the reverse order.
The `num-blocks` and `sector-length` properties work exactly as they di
After a flash device enters CFI mode from autoselect mode, the reset
command returns the device to autoselect mode. An additional reset
command is necessary to return to read array mode.
Signed-off-by: Stephen Checkoway
---
hw/block/pflash_cfi02.c | 21 +
tests/pflash-cfi02
The goal of this patch series implement the following AMD command-set parallel
flash functionality:
- flash interleaving;
- nonuniform sector sizes;
- erase suspend/resume commands; and
- multi-sector erase.
During refactoring and implementation, I discovered several bugs that are
fixed here as we
Simplify and refactor for upcoming commits. In particular, pull out all
of the code to modify the status into simple helper functions. Status
handling becomes more complex once multiple chips are interleaved to
produce a single device.
No change in functionality is intended with this commit.
Sign
Thanks Peter. I was just reading up on the CVE process and I agree.
Obviously, it's dangerous to use uninitialized values, but that doesn't
necessarily make it a vulnerability.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://
And thank you Thomas for the instructions!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1825002
Title:
"qemu: Unexpected FPU mode" since
0c1bbedc10e86ea9366b6af8c5520fafa3266b2f
Status in QEMU:
> From: Mateja Marjanovic
> Subject: [PATCH v7 0/6] target/mips: Optimize MSA interleave instructions
>
> From: Mateja Marjanovic
>
> Optimize and refactor MSA instructions ILVEV.,
> ILVOD., ILVL. and ILVR..
Patch number 5/6 seems to be for some reason lost. Please resend the
complete series.
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
This is certainly a bug, but it's not a a CVE, ie not a security bug.
The entire purpose of the linux-user mode is to run the guest ELF file
and let it perform whatever syscalls it likes -- it doesn't need to
exploit any kind of bug in the ELF loader to be able to control what the
process is doing.
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
> From: Aleksandar Markovic
> Subject: Re: [PATCH] target/mips: Amend tests for MSA binary integer
> operations
>
> > From: Mateja Marjanovic
> > Subject: [PATCH] target/mips: Amend tests for MSA binary integer operations
> >
> > Amend tests for certain MSA binary integer instructions
> > (for e
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
On Tue, 2019-04-16 at 15:50 +0200, Paolo Bonzini wrote:
> On 15/04/19 15:57, Maxim Levitsky wrote:
> >
> >
> > Hi!
> > These are few assorted fixes and features for the userspace
> > nvme driver.
> >
> > Tested that on my laptop with my Samsung X5 thunderbolt drive, which
> > happens to have 4K
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
Currently the driver hardcodes the sector size to 512,
and doesn't check the underlying device
Also fail if underlying nvme device is formatted with metadata
as this needs special support.
Signed-off-by: Maxim Levitsky
---
block/nvme.c | 40 +++-
1 file chang
Signed-off-by: Maxim Levitsky
---
block/nvme.c | 80 ++
block/trace-events | 2 ++
2 files changed, 82 insertions(+)
diff --git a/block/nvme.c b/block/nvme.c
index 35b925899f..b83912c627 100644
--- a/block/nvme.c
+++ b/block/nvme.c
@@ -110,6 +11
Phase bits are only set by the hardware to indicate new completions
and not by the device driver.
Signed-off-by: Maxim Levitsky
---
block/nvme.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/block/nvme.c b/block/nvme.c
index 0684bbd077..2d208000df 100644
--- a/block/nvme.c
+++ b/block/nvm
Fix the math involving non standard doorbell stride
Signed-off-by: Maxim Levitsky
---
block/nvme.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/nvme.c b/block/nvme.c
index 2d208000df..208242cf1f 100644
--- a/block/nvme.c
+++ b/block/nvme.c
@@ -216,7 +216,7 @@ static
Hi!
These are few assorted fixes and features for the userspace
nvme driver.
Tested that on my laptop with my Samsung X5 thunderbolt drive, which
happens to have 4K sectors, support for discard and write zeros.
Also bunch of fixes sitting in my queue from the period when I developed
the nvme-mdev
Signed-off-by: Maxim Levitsky
---
block/nvme.c | 69 +++-
block/trace-events | 1 +
include/block/nvme.h | 19 +++-
3 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/block/nvme.c b/block/nvme.c
index 0b1da54574..35b925899f 1
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
What's a quick fix for stuff like this?
WARNING: ThreadSanitizer: data race (pid=168036)
Write of size 8 at 0x7b900017a100 by thread T1 (mutexes: write M2141):
#0 free
/toolchain/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:715:3
(qemu-system-x86_64+0x484028)
#1 phys_secti
In load_elf_binary, struct image_info interp_info is used without being
properly initialized. One result is that when the ELF's program header
doesn't contain an entry for the ABI flags, then the value of the struct
image_info's fp_abi field is set to whatever happened to be in stack
memory at the
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
On 4/17/19 2:18 PM, Markus Armbruster wrote:
> INIT_DISASSEMBLE_INFO() takes an fprintf()-like callback and a FILE *
> to pass to it. monitor_disas() passes monitor_fprintf() and the
> current monitor cast to FILE *. monitor_fprintf() casts it right
> back, and is otherwise identical to monitor_p
Patchew URL: https://patchew.org/QEMU/20190417191805.28198-1-arm...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190417191805.28198-1-arm...@redhat.com
Subject: [Qemu-devel] [PATCH v2 00/17] Clean up and simplify aro
On 4/17/19 5:33 AM, Mateja Marjanovic wrote:
> From: Mateja Marjanovic
>
> Optimize set of MSA instructions ILVEV., using
> directly tcg registers and performing logic on them
> instead of using helpers.
>
> In the following table, the first column is the performance
> before this patch. The sec
On 4/17/19 5:33 AM, Mateja Marjanovic wrote:
> From: Mateja Marjanovic
>
> Optimize set of MSA instructions ILVOD., using
> directly tcg registers and performing logic on them instead
> of using helpers.
>
> In the following table, the first column is the performance
> before this patch. The sec
On 4/17/19 2:06 PM, Markus Armbruster wrote:
> char_pty_open() prints a "char device redirected to PTY_NAME (label
> LABEL)" message to the current monitor or else to stderr. This is not
> an error, so it shouldn't go to stderr. Print it to stdout instead.
>
> Why is it even printed? No other C
The various dump_mmu() take an fprintf()-like callback and a FILE * to
pass to it, and so do their helper functions. Passing around callback
and argument is rather tiresome.
Most dump_mmu() are called only by the target's hmp_info_tlb(). These
all pass monitor_printf() cast to fprintf_function a
On Wed, Apr 17, 2019 at 10:53:04PM +0800, Pu Wen wrote:
> On 2019/4/16 22:17, Pavel Hrdina wrote:
> > On Tue, Apr 16, 2019 at 08:06:13PM +0800, Pu Wen wrote:
> > > Add a new base CPU model called 'Dhyana' to model processors from Hygon
> > > Dhyana(family 18h), which derived from AMD EPYC(family 17
Code that doesn't want to know about current monitor vs. stdout
vs. stderr takes an fprintf_function callback and a FILE * argument to
pass to it. Actual arguments are either fprintf() and stdout or
stderr, or monitor_fprintf() and the current monitor cast to FILE *.
monitor_fprintf() casts it rig
bdrv_snapshot_dump(), bdrv_image_info_specific_dump(),
bdrv_image_info_dump() and their helpers take an fprintf()-like
callback and a FILE * to pass to it.
hmp.c passes monitor_printf() cast to fprintf_function and the current
monitor cast to FILE *.
qemu-img.c and qemu-io-cmds.c pass fprintf and
CPUClass method dump_statistics() takes an fprintf()-like callback and
a FILE * to pass to it. Most callers pass fprintf() and stderr.
log_cpu_state() passes fprintf() and qemu_log_file.
hmp_info_registers() passes monitor_fprintf() and the current monitor
cast to FILE *. monitor_fprintf() casts
We pass around fprintf_function callbacks together a FILE * argument.
Three cases:
* We pass fprintf() and stdout, stderr or qemu_log_file. Okay.
* We pass monitor_fprintf() together with the current monitor cast to
FILE *. The type-punning is ugly.
* We pass monitor_printf() cast to fprintf
INIT_DISASSEMBLE_INFO() takes an fprintf()-like callback and a FILE *
to pass to it. monitor_disas() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to monitor_printf(). The
type-pinning is ugly.
Pass qemu_fprint
mtree_info() takes an fprintf()-like callback and a FILE * to pass to
it, and so do its helper functions. Passing around callback and
argument is rather tiresome.
Its only caller hmp_info_mtree() passes monitor_printf() cast to
fprintf_function and the current monitor cast to FILE *.
The type-pu
The various TARGET_cpu_list() take an fprintf()-like callback and a
FILE * to pass to it. Their callers (vl.c's main() via list_cpus(),
bsd-user/main.c's main(), linux-user/main.c's main()) all pass
fprintf() and stdout. Thus, the flexibility provided by the (rather
tiresome) indirection isn't ac
dump_opcount_info() takes an fprintf()-like callback and a FILE * to
pass to it.
Its only caller hmp_info_opcount() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to monitor_printf(). The
type-punning is ugly.
D
CPUClass method dump_statistics() takes an fprintf()-like callback and
a FILE * to pass to it.
Its only caller hmp_info_cpustats() (via cpu_dump_statistics()) passes
monitor_fprintf() and the current monitor cast to FILE *.
monitor_fprintf() casts it right back, and is otherwise identical to
monit
dump_drift_info() takes an fprintf()-like callback and a FILE * to pass
to it.
Its only caller hmp_info_jit() passes monitor_fprintf() and a Monitor
* cast to FILE *. monitor_fprintf() casts it right back, and is
otherwise identical to monitor_printf(). The type-punning is ugly.
Drop the callba
Commit dc99065b5f9 (v0.1.0) added dis-asm.h from binutils.
Commit 43d4145a986 (v0.1.5) inlined bfd.h into dis-asm.h to remove the
dependency on binutils.
Commit 76cad71136b (v1.4.0) moved dis-asm.h to include/disas/bfd.h.
The new name is confusing when you try to match against (pre GPLv3+)
binuti
Signed-off-by: Markus Armbruster
Reviewed-by: Dr. David Alan Gilbert
---
include/qemu-common.h | 2 --
include/qemu/cutils.h | 2 --
include/sysemu/cpus.h | 1 +
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/qemu-common.h b/include/qemu-common.h
index a102245519..f891e05e
st_print_trace_file_status() takes an fprintf()-like callback and a
FILE * to pass to it.
Its only caller hmp_trace_file() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to monitor_printf(). The
type-punning is u
The previous commits have eliminated fprintf_function outside
disassemblers, simplifying code and cleaning up the ugly type-punning
fprintf_function seems to attract. Move fprintf_function to
include/disas/dis-asm.h to reduce the temptation to abuse it.
I considered renaming it to fprintf_ftype (
x86_cpu_dump_local_apic_state() takes an fprintf()-like callback and a
FILE * to pass to it, and so do its helper functions.
Its only caller hmp_info_local_apic() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to
dump_exec_info() takes an fprintf()-like callback and a FILE * to pass
to it.
Its only caller hmp_info_jit() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to monitor_printf(). The
type-punning is ugly.
Drop the
Callbacks ssh_co_readv(), ssh_co_writev(), ssh_co_flush() report
errors to the user with error_printf(). They shouldn't, it's their
caller's job. Replace by a suitable trace point. While there, drop
the unreachable !s->sftp case.
Perhaps we should convert this part of the block driver interface
qsp_report() takes an fprintf()-like callback and a FILE * to pass to
it.
Its only caller hmp_sync_profile() passes monitor_fprintf() and the
current monitor cast to FILE *. monitor_fprintf() casts it right
back, and is otherwise identical to monitor_printf(). The
type-punning is ugly.
Drop the
Cc: Alex Williamson
Signed-off-by: Markus Armbruster
---
hw/vfio/pci.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 504019c458..0142819ea6 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -947,8 +947,10 @@ static vo
We commonly want to print to the current monitor if we have one, else
to stdout/stderr. For stderr, have error_printf(). For stdout, all
we have is monitor_vfprintf(), which is rather unwieldy. We often
print to stderr just because error_printf() is easier.
New qemu_printf() and qemu_vprintf()
printf() & friends return the number of characters written on success,
negative value on error.
monitor_printf(), monitor_vfprintf(), monitor_vprintf(),
error_printf(), error_printf_unless_qmp(), error_vprintf(), and
error_vprintf_unless_qmp() return void. Some of them carry a TODO
comment asking
error_exit() uses low-level error_printf() to report errors.
Modernize it to use error_vreport().
Cc: Kevin Wolf
Cc: Max Reitz
Cc: qemu-bl...@nongnu.org
Signed-off-by: Markus Armbruster
Reviewed-by: Eric Blake
---
qemu-img.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Signed-off-by: Markus Armbruster
---
hw/timer/hpet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
index d97436bc7b..41024f39fb 100644
--- a/hw/timer/hpet.c
+++ b/hw/timer/hpet.c
@@ -744,7 +744,7
Command line help explicitly requested by the user should be printed
to stdout, not stderr. We do elsewhere. Adjust -drive to match: use
qemu_printf() instead of error_printf(). Plain printf() would be
wrong because we need to print to the current monitor for "drive_add
... format=help".
Cc: Ke
Cc: "Michael S. Tsirkin"
Cc: Marcel Apfelbaum
Signed-off-by: Markus Armbruster
Reviewed-by: Marcel Apfelbaum
---
hw/pci/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 6d13ef877b..1808b242dd 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.
kvm_s390_mem_op() can fail in two ways: when !cap_mem_op, it returns
-ENOSYS, and when kvm_vcpu_ioctl() fails, it returns -errno set by
ioctl(). Its caller s390_cpu_virt_mem_rw() recovers from both
failures.
kvm_s390_mem_op() prints "KVM_S390_MEM_OP failed" with error_printf()
in the latter failu
Command line help explicitly requested by the user should be printed
to stdout, not stderr. We do elsewhere. Adjust -chardev to match:
use qemu_printf() instead of error_printf(). Plain printf() would be
wrong because we need to print to the current monitor for "chardev-add
help".
Cc: "Marc-And
Command line help help explicitly requested by the user should be
printed to stdout, not stderr. We do elsewhere. Adjust -machine
$TYPE,help and -accel help to match: use printf() instead of
error_printf().
Cc: Marcel Apfelbaum
Signed-off-by: Markus Armbruster
Reviewed-by: Marcel Apfelbaum
--
1 - 100 of 188 matches
Mail list logo
