On Mon, 12 Aug 2019 15:37:39 +0200
David Hildenbrand wrote:
> On 12.08.19 13:27, David Hildenbrand wrote:
> > Instructions are always fetched from primary address space, except when
> > in home address mode. Perform the selection directly in cpu_mmu_index().
> >
> > get_mem_index() is only used
On 13.08.19 08:54, Thomas Huth wrote:
> On 8/12/19 9:20 PM, Max Reitz wrote:
>> On 12.08.19 21:14, John Snow wrote:
>>>
>>>
>>> On 7/22/19 8:58 AM, Thomas Huth wrote:
Not sure if it has been reported before, but test 059 currently fails:
059 fail [14:55:21] [14:55:26]
Hi David,
On 8/13/19 12:29 PM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> MemoryRegionSection includes an Int128 'size' field;
> on some platforms the compiler causes an alignment of this to
> a 128bit boundary, leaving 8 bytes of dead space.
> This deadspace can be
We should avoid including the whole of softfloat headers in cpu.h and
explicitly include it only where we will be calling softfloat
functions. We can use the -types.h and -helpers.h in cpu.h for the few
bits that are global.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
Reviewed-by:
On Mon, 12 Aug 2019 at 09:38, Peter Maydell wrote:
>
> On Sun, 11 Aug 2019 at 08:17, Bin Meng wrote:
> >
> > Hi Palmer,
> >
> > On Tue, Aug 6, 2019 at 1:04 AM Alistair Francis
> > wrote:
> > >
> > > On Fri, Aug 2, 2019 at 11:08 PM Bin Meng wrote:
> > > >
> > > > Currently the make rules are wr
On 8/13/19 1:49 PM, Alex Bennée wrote:
> We have a wrapper that does the right thing from stdint.h so lets use
> it for our constants in softfloat-specialize.h
>
> Signed-off-by: Alex Bennée
> ---
> fpu/softfloat-specialize.h | 26 +-
> 1 file changed, 13 insertions(+), 1
On 12.08.19 23:16, John Snow wrote:
>
>
> On 8/12/19 5:03 PM, Max Reitz wrote:
>> On 12.08.19 22:26, John Snow wrote:
>>>
>>>
>>> On 7/25/19 11:57 AM, Max Reitz wrote:
Compressed writes generally have to write full clusters, not just in
theory but also in practice when it comes to vmdk'
13.08.2019 14:51, Kevin Wolf wrote:
> Am 13.08.2019 um 13:14 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 13.08.2019 12:33, Vladimir Sementsov-Ogievskiy wrote:
>>> 13.08.2019 12:01, Vladimir Sementsov-Ogievskiy wrote:
13.08.2019 11:39, Vladimir Sementsov-Ogievskiy wrote:
> 12.08.2019 2
On 8/13/19 2:49 PM, Alex Bennée wrote:
> We should avoid including the whole of softfloat headers in cpu.h and
> explicitly include it only where we will be calling softfloat
> functions. We can use the -types.h and -helpers.h in cpu.h for the few
> bits that are global.
>
> Signed-off-by: Alex Be
On 8/13/19 3:57 AM, Paolo Bonzini wrote:
> On 13/08/19 08:17, Thomas Huth wrote:
>> On 8/12/19 9:16 PM, John Snow wrote:
>>>
>>>
>>> On 7/25/19 4:34 AM, Thomas Huth wrote:
On 24/07/2019 18.29, Paolo Bonzini wrote:
> On 24/07/19 11:34, Thomas Huth wrote:
>> In case somebody is intere
On 8/13/19 1:49 PM, Alex Bennée wrote:
> +static FloatParts parts_squash_denormal(FloatParts p, float_status *status)
> +{
> +if (p.exp == 0 && p.frac != 0) {
> +float_raise(float_flag_input_denormal, status);
> +p.frac = 0;
> +p.cls = float_class_zero;
> +}
> +
> +
On 8/13/19 1:49 PM, Alex Bennée wrote:
> Using the floatXX_pack_raw functions is slight overkill for basically
> just masking out all but the top bit of the number. This makes the
> final code exactly the same as pre-conversion.
>
> TODO: is this worth it, can the compiler do better with make_floa
On Tue, Aug 13, 2019 at 2:21 PM Kevin Wolf wrote:
> Am 13.08.2019 um 12:45 hat Nir Soffer geschrieben:
> > On Mon, Aug 12, 2019 at 5:23 PM Kevin Wolf wrote:
> >
> > > Am 11.08.2019 um 22:50 hat Nir Soffer geschrieben:
> > > > In some cases buf_align or request_alignment cannot be detected:
> > >
On 8/13/19 1:49 PM, Alex Bennée wrote:
> Remove some more use of LIT64 while making the meaning more clear. We
> also avoid the need of casts as the results by definition fit into the
> return type.
>
> Signed-off-by: Alex Bennée
> ---
> fpu/softfloat.c | 30 ++
> 1 f
On 8/13/19 1:49 PM, Alex Bennée wrote:
> In our quest to eliminate the home rolled LIT64 macro we fixup usage
> inside for m68k's many constants.
>
> Signed-off-by: Alex Bennée
> ---
> target/m68k/softfloat.c | 98 -
> 1 file changed, 49 insertions(+), 49
On 8/13/19 1:49 PM, Alex Bennée wrote:
> In our quest to eliminate the home rolled LIT64 macro we fixup usage
> inside the softfloat code. While we are at it we remove some of the
> extraneous spaces to closer fit the house style.
>
> Signed-off-by: Alex Bennée
> ---
> fpu/softfloat.c
On 8/13/19 1:49 PM, Alex Bennée wrote:
> Now the rest of the code has been cleaned up we can remove this.
>
> Signed-off-by: Alex Bennée
> ---
> include/fpu/softfloat.h | 2 --
> 1 file changed, 2 deletions(-)
Reviewed-by: Richard Henderson
r~
On 8/13/19 2:49 PM, Alex Bennée wrote:
> Generally the cpu and non-FP helper files just want to manipulate the
> softfloat flags. For this they can just use the -helpers.h include
> which brings in a minimal number of inline helpers.
>
> Signed-off-by: Alex Bennée
> Reviewed-by: Richard Henderson
On Mon, 12 Aug 2019 13:27:33 +0200
David Hildenbrand wrote:
> Instructions are always fetched from primary address space, except when
> in home address mode. Perform the selection directly in cpu_mmu_index().
>
> get_mem_index() is only used to perform data access, instructions are
> fetched via
Patchew URL:
https://patchew.org/QEMU/20190813124946.25322-1-alex.ben...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v3 00/13] softfloat updates (include tweaks, rm
LIT64)
Message-id: 2019081312494
Am 13.08.2019 um 14:01 hat Kevin Wolf geschrieben:
> Am 13.08.2019 um 13:28 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > 13.08.2019 14:04, Kevin Wolf wrote:
> > > Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > >> BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fa
The -usb section of the man page is not very clear on what exactly -usb
does and fails to mention xHCI as a modern alternative (-device
nec-usb-xhci).
Signed-off-by: Stefan Hajnoczi
---
qemu-options.hx | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/qemu-options.hx b/q
Patchew URL:
https://patchew.org/QEMU/20190813124946.25322-1-alex.ben...@linaro.org/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v3 00/13] softfloat updates (include tweaks, rm
LIT64)
Message-id: 2019081312494
On Mon, Aug 12, 2019 at 06:18:43PM +0200, Paolo Bonzini wrote:
>On 18/07/19 03:04, Wei Yang wrote:
>> The value left in nr is the number of bits for the last word, which
>> could be calculate the last word mask directly.
>>
>> Remove the unnecessary size.
>
>Hi,
>
>the value left in nr is _not_ th
Richard Henderson writes:
> On 8/13/19 1:49 PM, Alex Bennée wrote:
>> +static FloatParts parts_squash_denormal(FloatParts p, float_status *status)
>> +{
>> +if (p.exp == 0 && p.frac != 0) {
>> +float_raise(float_flag_input_denormal, status);
>> +p.frac = 0;
>> +p.cls
On Mon, 12 Aug 2019 13:27:34 +0200
David Hildenbrand wrote:
> Whenever we modify a storage key, we shuld flush the TLBs of all CPUs,
> so the MMU fault handling code can properly consider the changed storage
> key (to e.g., properly set the reference and change bit on the next
> accesses).
>
> T
From: Philippe Mathieu-Daudé
Add a test of the NeXTcube framebuffer using the Tesseract OCR
engine on a screenshot of the framebuffer device.
The test is very quick:
$ avocado --show=app,console run tests/acceptance/machine_m68k_nextcube.py
JOB ID : 78844a92424cc495bd068c3874d542d1e20f2
From: Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé
---
v2:
- install tesseract English package (Thomas)
- install PIL
---
.travis.yml | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index caf0a1f8fa..f6dea2492c 100644
--- a/.tr
Hi,
I was looking at Thomas' last series [*] where he adds the
NeXTcube machine, thinking about enforcing a new rule "new
machines must have tests". Then I realized the UART is not
emitting characters, so our current sample tests are not
helpful.
Since the framebuffer is working, I gave a try at
Proof of concept to interract with a framebuffer via VNC.
This test send 'mem' and 'help' to the firmware prompt
within the single X terminal opened.
Signed-off-by: Philippe Mathieu-Daudé
---
This test is limited because the '-vnc' option only allow
to bind TCP port. To allow parallel testing, I
Alex Bennée writes:
> Hi,
>
> Another iteration of updates for softfloat. Instead of moving the
> LIT64() macro from one file to another we convert the uses to the
> stdint.h macro. I did eliminate one of the uses by converting the
> squash_input_denormal functions to the new style code. However
On 12.08.19 23:33, John Snow wrote:
>
>
> On 7/25/19 11:57 AM, Max Reitz wrote:
>> Several vmdk subformats do not work with iotest 126, so disable them.
>>
>> (twoGbMaxExtentSparse actually should work, but fixing that is a bit
>> difficult. The problem is that the vmdk descriptor file will cont
On 7/15/19 3:13 PM, Thomas Huth wrote:
> On 12/07/2019 15.39, Philippe Mathieu-Daudé wrote:
>> A series of obvious patches to build without the deprecated
>> bluetooth devices. Still worth for 4.1 or too late?
>> It is clearly not a bugfix.
>
> I wonder whether this series is worth the effort righ
On Tue, 13 Aug 2019 at 15:01, Philippe Mathieu-Daudé wrote:
>
> On 7/15/19 3:13 PM, Thomas Huth wrote:
> > On 12/07/2019 15.39, Philippe Mathieu-Daudé wrote:
> >> A series of obvious patches to build without the deprecated
> >> bluetooth devices. Still worth for 4.1 or too late?
> >> It is clearly
On Tue, Aug 13, 2019 at 04:41:49PM +0800, Jason Wang wrote:
> Do we need a generic solution other than an Intel specific one?
I assume you're asking about ARM not AMD, right? :)
Yes I think we should have a generic solution. Though I'd like to see
whether this idea can be accepted first, then we
12.08.2019 19:37, Vladimir Sementsov-Ogievskiy wrote:
> 12.08.2019 19:11, Max Reitz wrote:
>> On 12.08.19 17:47, Vladimir Sementsov-Ogievskiy wrote:
>>> 12.08.2019 18:10, Max Reitz wrote:
On 10.08.19 21:31, Vladimir Sementsov-Ogievskiy wrote:
> backup_cow_with_offload can transfer more tha
Markus Armbruster writes:
> Alex Bennée writes:
>
>> Hi,
>>
>> Another iteration of updates for softfloat. Instead of moving the
>> LIT64() macro from one file to another we convert the uses to the
>> stdint.h macro. I did eliminate one of the uses by converting the
>> squash_input_denormal fu
Hi,
this message is a problem statement, and an initial recommendation for
solving it, from Jiewen, Paolo, Yingwen, and others. I'm cross-posting
the thread starter to the ,
and lists. Please use "Reply All" when
commenting.
In response to the initial posting, I plan to ask a number of question
On 13.08.19 16:14, Vladimir Sementsov-Ogievskiy wrote:
> 12.08.2019 19:37, Vladimir Sementsov-Ogievskiy wrote:
>> 12.08.2019 19:11, Max Reitz wrote:
>>> On 12.08.19 17:47, Vladimir Sementsov-Ogievskiy wrote:
12.08.2019 18:10, Max Reitz wrote:
> On 10.08.19 21:31, Vladimir Sementsov-Ogievsk
On 13.08.19 13:51, Kevin Wolf wrote:
[...]
> Hm... This is a mess. :-)
Just out of curiosity: Why?
Aren’t there only two things we really need from the block_status
infrastructure?
(1) Whether something is allocated in the given layer of the backing chain,
(2) Whether we know that a given ran
On 13/08/19 12:31, Philippe Mathieu-Daudé wrote:
>> |
>> | s->istat1 |= LSI_ISTAT1_SRUN;
>> | again:
>> | -insn_processed++;
>> | +if (++insn_processed > LSI_MAX_INSN) {
>> | +trace_lsi_execute_script_tc_illegal();
>> | +lsi_script_dma_interrupt(s, LSI_DSTAT_IID);
>>
On 13.08.19 11:34, Kevin Wolf wrote:
> Am 12.08.2019 um 21:46 hat Max Reitz geschrieben:
>> On 12.08.19 20:11, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all!
>>>
>>> I'm not sure, is it a bug or a feature, but using qcow2 under raw is
>>> broken. It should be either fixed like I propose (by Max's
13.08.2019 17:23, Max Reitz wrote:
> On 13.08.19 16:14, Vladimir Sementsov-Ogievskiy wrote:
>> 12.08.2019 19:37, Vladimir Sementsov-Ogievskiy wrote:
>>> 12.08.2019 19:11, Max Reitz wrote:
On 12.08.19 17:47, Vladimir Sementsov-Ogievskiy wrote:
> 12.08.2019 18:10, Max Reitz wrote:
>> On
On 13.08.19 13:04, Kevin Wolf wrote:
> Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to
>> returned file. But is it correct behavior at all? If returned file
>> itself has a backing file, we may report as tot
On 13.08.19 15:21, Kevin Wolf wrote:
> Am 13.08.2019 um 14:01 hat Kevin Wolf geschrieben:
>> Am 13.08.2019 um 13:28 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>> 13.08.2019 14:04, Kevin Wolf wrote:
Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
> BDRV_BLOCK_RAW ma
13.08.2019 17:31, Max Reitz wrote:
> On 13.08.19 13:51, Kevin Wolf wrote:
>
> [...]
>
>> Hm... This is a mess. :-)
>
> Just out of curiosity: Why?
>
> Aren’t there only two things we really need from the block_status
> infrastructure?
>
> (1) Whether something is allocated in the given layer o
ad66012b2cfb2035003c37eef:
> > >
> > > display/bochs: fix pcie support (2019-08-12 16:36:41 +0100)
> > >
> > > are available in the Git repository at:
> > >
> > > git://github.com/dgibson/qemu.git tags/ppc-for-4.1-20190813
> > &g
On Tue, Aug 13, 2019 at 01:00:24PM +0530, Aravinda Prasad wrote:
>
>
> On Monday 12 August 2019 03:38 PM, David Gibson wrote:
> > On Mon, Aug 05, 2019 at 02:14:39PM +0530, Aravinda Prasad wrote:
> >> Alexey/David,
> >>
> >> With the SLOF changes, QEMU cannot resize the RTAS blob. Resizing is
> >>
On 12.08.19 23:45, John Snow wrote:
>
>
> On 8/12/19 3:11 PM, Max Reitz wrote:
>> On 12.08.19 20:39, John Snow wrote:
>>>
>>>
>>> On 7/25/19 11:55 AM, Max Reitz wrote:
Hi,
69f47505ee66afaa513305de0c1895a224e52c45 changed block_status so that it
would only go down to the protoc
On 13.08.19 12:38, Kevin Wolf wrote:
> Am 12.08.2019 um 17:56 hat Max Reitz geschrieben:
>> On 12.08.19 17:33, Vladimir Sementsov-Ogievskiy wrote:
>>> 25.07.2019 18:55, Max Reitz wrote:
vpc is not really a passthrough driver, even when using the fixed
subformat (where host and guest offse
On 8/13/19 9:31 AM, Max Reitz wrote:
> On 13.08.19 13:51, Kevin Wolf wrote:
>
> [...]
>
>> Hm... This is a mess. :-)
>
> Just out of curiosity: Why?
>
> Aren’t there only two things we really need from the block_status
> infrastructure?
>
> (1) Whether something is allocated in the given layer
On 13.08.19 16:46, Vladimir Sementsov-Ogievskiy wrote:
> 13.08.2019 17:31, Max Reitz wrote:
>> On 13.08.19 13:51, Kevin Wolf wrote:
>>
>> [...]
>>
>>> Hm... This is a mess. :-)
>>
>> Just out of curiosity: Why?
>>
>> Aren’t there only two things we really need from the block_status
>> infrastructur
On Mon, 12 Aug 2019 13:27:36 +0200
David Hildenbrand wrote:
> Any access sets the reference bit. In case we have a read-fault, we
> should not allow writes to the TLB entry if the change bit was not
> already set.
>
> This is a preparation for proper storage-key reference/change bit handling
> i
13.08.2019 17:43, Max Reitz wrote:
> On 13.08.19 13:04, Kevin Wolf wrote:
>> Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>> BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to
>>> returned file. But is it correct behavior at all? If returned file
>>> itself
On 13.08.19 16:39, Vladimir Sementsov-Ogievskiy wrote:
> 13.08.2019 17:23, Max Reitz wrote:
>> On 13.08.19 16:14, Vladimir Sementsov-Ogievskiy wrote:
>>> 12.08.2019 19:37, Vladimir Sementsov-Ogievskiy wrote:
12.08.2019 19:11, Max Reitz wrote:
> On 12.08.19 17:47, Vladimir Sementsov-Ogievsk
On Tue, Aug 13, 2019 at 11:30:41AM +0200, Thomas Huth wrote:
> While global_qtest and its wrapper functions work fine for tests that only
> run one instance of QEMU, using the global_qtest variable in our qtests is
> very problematic for tests that use multiple test states (e.g. migration
> tests).
13.08.2019 17:57, Max Reitz wrote:
> On 13.08.19 16:39, Vladimir Sementsov-Ogievskiy wrote:
>> 13.08.2019 17:23, Max Reitz wrote:
>>> On 13.08.19 16:14, Vladimir Sementsov-Ogievskiy wrote:
12.08.2019 19:37, Vladimir Sementsov-Ogievskiy wrote:
> 12.08.2019 19:11, Max Reitz wrote:
>> On
On Fri, 9 Aug 2019 14:57:25 +0800
Tao wrote:
> 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
> defin
On 13.08.19 17:00, Vladimir Sementsov-Ogievskiy wrote:
> 13.08.2019 17:57, Max Reitz wrote:
>> On 13.08.19 16:39, Vladimir Sementsov-Ogievskiy wrote:
>>> 13.08.2019 17:23, Max Reitz wrote:
On 13.08.19 16:14, Vladimir Sementsov-Ogievskiy wrote:
> 12.08.2019 19:37, Vladimir Sementsov-Ogievsk
Am 13.08.2019 um 16:53 hat Max Reitz geschrieben:
> On 13.08.19 16:46, Vladimir Sementsov-Ogievskiy wrote:
> > 13.08.2019 17:31, Max Reitz wrote:
> >> On 13.08.19 13:51, Kevin Wolf wrote:
> >>
> >> [...]
> >>
> >>> Hm... This is a mess. :-)
> >>
> >> Just out of curiosity: Why?
> >>
> >> Aren’t the
On 13.08.19 16:56, Vladimir Sementsov-Ogievskiy wrote:
> 13.08.2019 17:43, Max Reitz wrote:
>> On 13.08.19 13:04, Kevin Wolf wrote:
>>> Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to
returned file. B
On 13.08.19 17:03, Kevin Wolf wrote:
> Am 13.08.2019 um 16:53 hat Max Reitz geschrieben:
>> On 13.08.19 16:46, Vladimir Sementsov-Ogievskiy wrote:
>>> 13.08.2019 17:31, Max Reitz wrote:
On 13.08.19 13:51, Kevin Wolf wrote:
[...]
> Hm... This is a mess. :-)
Just out
On Mon, 12 Aug 2019 13:27:37 +0200
David Hildenbrand wrote:
> Factor it out, add a comment how it all works, and also use it in the
> REAL MMU.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mmu_helper.c | 114 +++---
> 1 file changed, 69 insertions(+
On 8/9/19 1:57 AM, Tao wrote:
> 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
On 8/13/19 4:30 AM, Thomas Huth wrote:
> The libqos library functions should never depend on global_qtest,
> since these functions might be used in tests that track multiple
> test states. Pass around a pointer to the QTestState instead.
Thanks for picking up on my initial RFC along these lines a
On Wed, 31 Jul 2019 05:49:15 PDT (-0700), bmeng...@gmail.com wrote:
This adds 'info mem' command for RISC-V, to show virtual memory
mappings that aids debugging.
Rather than showing every valid PTE, the command compacts the
output by merging all contiguous physical address mappings into
one bloc
On 8/13/19 4:30 AM, Thomas Huth wrote:
> The libqos library functions should never depend on global_qtest,
> since these functions might be used in tests that track multiple
> test states. So let's use the test state of the QPCIDevice instead.
>
> Signed-off-by: Thomas Huth
> ---
> tests/libqos/
On 8/13/19 4:30 AM, Thomas Huth wrote:
> No test is using hmp() anymore, and since this function uses the disliked
> global_qtest variable, we should also make sure that nobody adds new code
> with this function again. qtest_hmp() should be used instead.
>
> Signed-off-by: Thomas Huth
> ---
> te
On 8/13/19 4:30 AM, Thomas Huth wrote:
> The generic libqtest library functions should not use functions that
> require the global_qtest variable.
>
> Signed-off-by: Thomas Huth
> ---
> tests/libqtest.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Reviewed-by: Eric Blake
-
13.08.2019 18:03, Max Reitz wrote:
> On 13.08.19 16:56, Vladimir Sementsov-Ogievskiy wrote:
>> 13.08.2019 17:43, Max Reitz wrote:
>>> On 13.08.19 13:04, Kevin Wolf wrote:
Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
> BDRV_BLOCK_RAW makes generic bdrv_co_block_statu
On 8/13/19 4:30 AM, Thomas Huth wrote:
> Generic library functions like qtest_qmp_device_add() and _del()
> should not depend on the global_qtest variable. Pass the test
> state via parameter instead.
>
> Signed-off-by: Thomas Huth
> ---
Reviewed-by: Eric Blake
--
Eric Blake, Principal Softwa
On 8/13/19 4:30 AM, Thomas Huth wrote:
> The normal libqtest library functions should never depend on global_qtest.
> Pass in the test state via parameter instead. And while we're at it,
> also rename this function to qtest_qmp_assert_success() to make it clear
> that it is part of libqtest.
>
> S
13.08.2019 18:02, Max Reitz wrote:
> On 13.08.19 17:00, Vladimir Sementsov-Ogievskiy wrote:
>> 13.08.2019 17:57, Max Reitz wrote:
>>> On 13.08.19 16:39, Vladimir Sementsov-Ogievskiy wrote:
13.08.2019 17:23, Max Reitz wrote:
> On 13.08.19 16:14, Vladimir Sementsov-Ogievskiy wrote:
>> 12
Am 13.08.2019 um 16:43 hat Max Reitz geschrieben:
> On 13.08.19 13:04, Kevin Wolf wrote:
> > Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to
> >> returned file. But is it correct behavior at all? If return
migration/qemu-file.h neglects to include it even though it needs
ram_addr_t. Fix that. Drop a few superfluous inclusions elsewhere.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20190812052359.30071-14-arm...@redhat.com>
-
TYPE_IOMMU_MEMORY_REGION is a direct subtype of TYPE_MEMORY_REGION.
Its instance struct is IOMMUMemoryRegion, and its first member is a
MemoryRegion. Correct. Its class struct is IOMMUMemoryRegionClass,
and its first member is a DeviceClass. Wrong. Messed up when commit
1221a474676 introduced t
Back in 2016, we discussed[1] rules for headers, and these were
generally liked:
1. Have a carefully curated header that's included everywhere first. We
got that already thanks to Peter: osdep.h.
2. Headers should normally include everything they need beyond osdep.h.
If exceptions are need
In my "build everything" tree, changing a type in qapi/common.json
triggers a recompile of some 3600 out of 6600 objects (not counting
tests and objects that don't depend on qemu/osdep.h).
One common dependency is QapiErrorClass: it's used only in in
qapi/error.h, which uses nothing else, and is w
Some of the generated qapi-types-MODULE.h are included all over the
place. Changing a QAPI type can trigger massive recompiling. Top
scorers recompile more than 1000 out of some 6600 objects (not
counting tests and objects that don't depend on qemu/osdep.h):
6300 qapi/qapi-builtin-types.h
hw/tpm/trace-events uses TARGET_FMT_plx formats with uint64_t
arguments. That's wrong, TARGET_FMT_plx takes hwaddr. Since hwaddr
happens to be uint64_t, it works anyway. Messed up in commit
ec427498da5, v2.12.0. Clean up by replacing TARGET_FMT_plx with its
macro expansion.
scripts/tracetool/f
docs/devel/tracing.txt explains "since many source files include
trace.h, [the generated trace.h use] a minimum of types and other
header files included to keep the namespace clean and compile times
and dependencies down."
Commit 4815185902 "trace: Add per-vCPU tracing states for events with
the '
We declare incomplete struct VMStateDescription in a couple of places
so we don't have to include migration/vmstate.h for the typedef.
That's fine with me. However, the next commit will drop
migration/vmstate.h from a massive number of compiles. Move the
typedef to qemu/typedefs.h now, so I don't
hw/hw.h used to include headers hardware emulation "usually" needs.
The previous commits removed all but one of them, to good effect.
Only qom/object.h is left. Remove that one, too.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Message-
When commit 5f7d05ecfda added QLIST_INSERT_HEAD_RCU() to qemu/queue.h,
it had to include qemu/atomic.h. Commit 341774fe6cc removed
QLIST_INSERT_HEAD_RCU() again, but neglected to remove the #include.
Do that now.
Signed-off-by: Markus Armbruster
Reviewed-by: Thomas Huth
Reviewed-by: Philippe Ma
In my "build everything" tree, changing migration/qemu-file-types.h
triggers a recompile of some 2600 out of 6600 objects (not counting
tests and objects that don't depend on qemu/osdep.h).
The culprit is again hw/hw.h, which supposedly includes it for
convenience.
Include migration/qemu-file-typ
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20190812052359.30071-20-arm...@redhat.com>
---
include/exec/cpu-defs.h | 1 -
include/hw/xen/xen_common.h | 1 -
include/net/can_emu.h | 1 +
include/net/filter.h
In my "build everything" tree, changing sysemu/reset.h triggers a
recompile of some 2600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h).
The main culprit is hw/hw.h, which supposedly includes it for
convenience.
Include sysemu/reset.h only where it's needed
While there, drop the obsolete file comment.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20190812052359.30071-12-arm...@redhat.com>
Reviewed-by: Alex Bennée
---
include/qemu/typedefs.h | 12
1 file changed, 8
Drop unnecessary inclusions from headers. Downgrade a few more to
exec/hwaddr.h.
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20190812052359.30071-17-arm...@redhat.com>
---
hw/audio/lm4549.h | 1 +
hw/net
hw/boards.h pulls in almost 60 headers. The less we include it into
headers, the better. As a first step, drop superfluous inclusions,
and downgrade some more to what's actually needed. Gets rid of just
one inclusion into a header.
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Signed-off-by: Marku
In my "build everything" tree, changing sysemu/sysemu.h triggers a
recompile of some 5400 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h).
Almost a third of its inclusions are actually superfluous. Delete
them. Downgrade two more to qapi/qapi-types-run-stat
The following changes since commit 864ab314f1d924129d06ac7b571f105a2b76a4b2:
Update version for v4.1.0-rc4 release (2019-08-06 17:05:21 +0100)
are available in the Git repository at:
git://repo.or.cz/qemu/armbru.git tags/pull-include-2019-08-13
for you to fetch changes up to 8d111fd683b678d
In my "build everything" tree, changing sysemu/sysemu.h triggers a
recompile of some 1800 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h, down from 5400 due to the
previous commit).
Several headers include sysemu/sysemu.h just to get typedef
VMChangeStateEntr
In my "build everything" tree, changing qemu/main-loop.h triggers a
recompile of some 5600 out of 6600 objects (not counting tests and
objects that don't depend on qemu/osdep.h). It includes block/aio.h,
which in turn includes qemu/event_notifier.h, qemu/notify.h,
qemu/processor.h, qemu/qsp.h, qem
Commit e35704ba9c "numa: Move NUMA declarations from sysemu.h to
numa.h" left a few NUMA-related macros behind. Move them now.
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Eduardo Habkost
Message-Id: <2019081205235
sysemu/numa.h includes hw/boards.h just for the CPUArchId typedef, at
the cost of pulling in more than two dozen extra headers indirectly.
I could move the typedef from hw/boards.h to qemu/typedefs.h. But
it's used in just two headers: boards.h and numa.h.
I could move it to another header both
In my "build everything" tree, changing hw/hw.h triggers a recompile
of some 2600 out of 6600 objects (not counting tests and objects that
don't depend on qemu/osdep.h).
The previous commits have left only the declaration of hw_error() in
hw/hw.h. This permits dropping most of its inclusions. To
Move the HostMemoryBackend typedef from sysemu/hostmem.h to
qemu/typedefs.h. This renders a few inclusions of sysemu/hostmem.h
superfluous; drop them.
Cc: Eduardo Habkost
Cc: Igor Mammedov
Signed-off-by: Markus Armbruster
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Eduardo Habkost
Revie
13.08.2019 18:41, Kevin Wolf wrote:
> Am 13.08.2019 um 16:43 hat Max Reitz geschrieben:
>> On 13.08.19 13:04, Kevin Wolf wrote:
>>> Am 12.08.2019 um 20:11 hat Vladimir Sementsov-Ogievskiy geschrieben:
BDRV_BLOCK_RAW makes generic bdrv_co_block_status to fallthrough to
returned file. But i
According to hw/ide/internal's file comment, only files in hw/ide/ are
supposed to include it. Drag reality slightly closer to supposition.
Three includes outside hw/ide remain: hw/arm/sbsa-ref.c,
include/hw/ide/pci.h, and include/hw/misc/macio/macio.h. Turns out
board code needs ide-internal.h
101 - 200 of 294 matches
Mail list logo
