On 13.02.20 19:32, Peter Xu wrote:
> On Thu, Feb 13, 2020 at 06:20:16PM +0100, David Hildenbrand wrote:
>> Resizing while migrating is dangerous and does not work as expected.
>> The whole migration code works on the usable_length of ram blocks and does
>> not expect this to change at random points
"Dr. David Alan Gilbert" wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
>> So we don't have to compile everything in, or have ifdefs
>>
>> Signed-off-by: Juan Quintela
>
> As far as I can tell this matches the way all the rest of the module
> stuff works, so:
>
> Reviewed-by: Dr. David Al
On 13.02.20 20:09, Juan Quintela wrote:
> David Hildenbrand wrote:
>> Resizing while migrating is dangerous and does not work as expected.
>> The whole migration code works on the usable_length of ram blocks and does
>> not expect this to change at random points in time.
>>
>> Precopy: The ram blo
Daniel P. Berrangé wrote:
> On Wed, Jan 29, 2020 at 12:56:48PM +0100, Juan Quintela wrote:
>> This will store the compression method to use. We start with none.
>>
>> Signed-off-by: Juan Quintela
>> Reviewed-by: Markus Armbruster
>> Reviewed-by: Dr. David Alan Gilbert
>> ---
>> hw/core/qdev-
David Hildenbrand wrote:
> Resizing while migrating is dangerous and does not work as expected.
> The whole migration code works on the usable_length of ram blocks and does
> not expect this to change at random points in time.
>
> Precopy: The ram block size must not change on the source, after
>
On 2/13/20 6:56 PM, Peter Maydell wrote:
The MigrationInfo::setup-time documentation is the only place where
we use _this_ inline markup for emphasis, commonly rendered in
italics. rST doesn't recognize that markup and emits literal
underscores.
Switch to *this* instead. Changes markup to stro
On 2/13/20 6:56 PM, Peter Maydell wrote:
For rST, '*' is a kind of inline markup (for emphasis), so
"*-softmmu" is a syntax error because of the missing closing '*'.
Escape the '*' with a '\'.
The texinfo document generator will leave the '\' in the
output, which is not ideal, but that generator
On Thu, 13 Feb 2020 at 00:23, Richard Henderson
wrote:
>
> The following changes since commit e18e5501d8ac692d32657a3e1ef545b14e72b730:
>
> Merge remote-tracking branch
> 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200210' into staging
> (2020-02-10 18:09:14 +)
>
> are available in the G
On Thu, 13 Feb 2020 at 18:38, Pierre Morel
wrote:> However it may be because I do not use the right tools.
> Did not find which one I am suppose to use.
> Currently using:
> rst2latex vfio-ap.rst > vfio-ap.tex && pdflatex vfio-ap.tex
The only supported way to build the docs is with Sphinx.
Optio
On Fri, 31 Jan 2020 17:02:46 PST (-0800), Alistair Francis wrote:
Mark both sstatus and vsstatus as dirty (3).
Signed-off-by: Alistair Francis
---
target/riscv/translate.c | 12
1 file changed, 12 insertions(+)
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
inde
On Fri, 31 Jan 2020 17:02:44 PST (-0800), Alistair Francis wrote:
When the Hypervisor extension is in use we only enable floating point
support when both status and vsstatus have enabled floating point
support.
Signed-off-by: Alistair Francis
---
target/riscv/cpu_helper.c | 3 +++
1 file chang
On 2020-02-13 17:29, Cornelia Huck wrote:
Move to system/, as this is mostly about configuring vfio-ap.
Signed-off-by: Cornelia Huck
---
MAINTAINERS | 2 +-
docs/system/index.rst| 1 +
docs/{vfio-ap.txt => system/vfio-ap.rst} | 796 +++
On Thu, Feb 13, 2020 at 06:20:16PM +0100, David Hildenbrand wrote:
> Resizing while migrating is dangerous and does not work as expected.
> The whole migration code works on the usable_length of ram blocks and does
> not expect this to change at random points in time.
>
> Precopy: The ram block si
On Fri, 31 Jan 2020 17:02:41 PST (-0800), Alistair Francis wrote:
Signed-off-by: Alistair Francis
---
target/riscv/cpu.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 5b889a0065..aa04e5cca7 100644
--- a/target/riscv/cpu.h
+
On 13.02.20 19:02, Jason J. Herne wrote:
> On 2/6/20 5:09 AM, Christian Borntraeger wrote:
>>
>>
>> On 05.02.20 19:21, Jason J. Herne wrote:
>>> This fixes vfio-ccw when booting non-Linux operating systems. Without this
>>> struct being packed, a few extra bytes of low core memory get overwritten
Since the topology routines have changed, update
the unit tests to use the new APIs.
Signed-off-by: Babu Moger
---
tests/test-x86-cpuid.c | 115
1 file changed, 68 insertions(+), 47 deletions(-)
diff --git a/tests/test-x86-cpuid.c b/tests/test-x
Apicid calculation depends on knowing the total number of numa nodes
for EPYC cpu models. Right now, we are calculating the arch_id while
parsing the numa(parse_numa). At this time, it is not known how many
total numa nodes are configured in the system.
Move the arch_id inside x86_cpus_init. At th
On 2/12/20 11:52 PM, Robert Hoo wrote:
> And initialize buffer_is_zero() with it, when Intel AVX512F is
> available on host.
>
> This function utilizes Intel AVX512 fundamental instructions which
> perform over previous AVX2 instructions.
Is it not still true that any AVX512 insn will cause the e
If the system is numa configured the pkg_offset needs
to be adjusted for EPYC cpu models. Fix it calling the
model specific handler.
Signed-off-by: Babu Moger
---
hw/i386/pc.c |1 +
hw/i386/x86.c |4
target/i386/cpu.c |4 ++--
target/i386/cpu.h |1 +
4 files changed
Add the new EPYC model specific handlers to fix the apicid decoding.
The APIC ID is decoded based on the sequence sockets->dies->cores->threads.
This works fine for most standard AMD and other vendors' configurations,
but this decoding sequence does not follow that of AMD's APIC ID enumeration
str
Check and Load the apicid handlers from X86CPUDefinition if available.
Update the calling convention for the apicid handlers.
Signed-off-by: Babu Moger
---
hw/i386/pc.c |6 +++---
hw/i386/x86.c | 27 +++
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git
Load the model specific handlers if available or else default handlers
will be loaded. Add the model specific handlers if apicid decoding
differs from the standard sequential numbering.
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 38 ++
target/i386/cpu
Use the new functions from topology.h and delete the unused code. Given the
sockets, nodes, cores and threads, the new functions generate apic id for EPYC
mode. Removes all the hardcoded values.
Signed-off-by: Babu Moger
---
target/i386/cpu.c | 162 +++---
Introduce model specific apicid functions inside X86MachineState.
These functions will be loaded from X86CPUDefinition.
Signed-off-by: Babu Moger
---
include/hw/i386/x86.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index 38c2d279
These functions add support for building EPYC mode topology given the smp
details like numa nodes, cores, threads and sockets.
The new apic id decoding is mostly similar to current apic id decoding
except that it adds a new field llc_id when numa configured. Removes all
the hardcoded values. Subse
This is an effort to re-arrange few data structure for better readability.
Add X86CPUTopoInfo which will have all the topology informations required
to build the cpu topology. There is no functional changes.
Signed-off-by: Babu Moger
Reviewed-by: Igor Mammedov
---
hw/i386/pc.c |
For consistancy rename apicid_from_topo_ids to x86_apicid_from_topo_ids.
No functional change.
Signed-off-by: Babu Moger
---
hw/i386/pc.c |2 +-
include/hw/i386/topology.h |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
On 2/6/20 5:09 AM, Christian Borntraeger wrote:
On 05.02.20 19:21, Jason J. Herne wrote:
This fixes vfio-ccw when booting non-Linux operating systems. Without this
struct being packed, a few extra bytes of low core memory get overwritten when
we assign a value to memory address 0 in jump_to_I
Store the smp sockets in CpuTopology. The socket information required to
build the apic id in EPYC mode. Right now socket information is not passed
to down when decoding the apic id. Add the socket information here.
Signed-off-by: Babu Moger
Reviewed-by: Eduardo Habkost
---
hw/core/machine.c
Update structures X86CPUTopoIDs and CPUX86State to hold the nodes_per_pkg.
This is required to build EPYC mode topology.
Signed-off-by: Babu Moger
---
hw/i386/pc.c |1 +
hw/i386/x86.c |2 ++
include/hw/i386/topology.h |2 ++
include/hw/i386/x86.h |
Initialize all the parameters in one function init_topo_info.
Move the data structure X86CPUTopoIDs and X86CPUTopoInfo into
x86.h.
Signed-off-by: Babu Moger
Reviewed-by: Eduardo Habkost
---
hw/i386/pc.c |4 +---
hw/i386/x86.c | 14 +++---
include/hw/i38
This series fixes APIC ID encoding problem reported on AMD EPYC cpu model.
https://bugzilla.redhat.com/show_bug.cgi?id=1728166
Currently, the APIC ID is decoded based on the sequence
sockets->dies->cores->threads. This works for most standard AMD and other
vendors' configurations, but this decodin
For rST, '*' is a kind of inline markup (for emphasis), so
"*-softmmu" is a syntax error because of the missing closing '*'.
Escape the '*' with a '\'.
The texinfo document generator will leave the '\' in the
output, which is not ideal, but that generator is going to
go away in a subsequent commit
Update the documentation of QAPI document comment syntax to match
the new rST backend requirements. The principal changes are:
* whitespace is now significant, and multiline definitions
must have their second and subsequent lines indented to
match the first line
* general rST format markup
Rename few data structures related to X86 topology. X86CPUTopoIDs will
have individual arch ids. Next patch introduces X86CPUTopoInfo which will
have all topology information(like cores, threads etc..).
Signed-off-by: Babu Moger
Reviewed-by: Eduardo Habkost
---
hw/i386/pc.c | 4
Now that we have all the parameters in X86CPUTopoInfo, we can just
pass the structure to calculate the offsets and width.
Signed-off-by: Babu Moger
Reviewed-by: Igor Mammedov
---
include/hw/i386/topology.h | 64 ++--
target/i386/cpu.c | 23 ++
As we accumulate lines from doc comments when parsing the JSON, the
QAPIDoc class generally strips leading and trailing whitespace using
line.strip() when it calls _append_freeform(). This is fine for
texinfo, but for rST leading whitespace is significant. We'd like to
move to having the text in
Convert qemu-qmp-ref to rST format. This includes dropping
the plain-text, pdf and info format outputs for this document;
as with all our other Sphinx-based documentation, we provide
HTML and manpage only.
The qemu-qmp-ref.rst is somewhat more stripped down than
the .texi was, because we do not (c
The MigrationInfo::setup-time documentation is the only place where
we use _this_ inline markup for emphasis, commonly rendered in
italics. rST doesn't recognize that markup and emits literal
underscores.
Switch to *this* instead. Changes markup to strong emphasis with
Texinfo, commonly rendered
Some of our documentation is auto-generated from documentation
comments in the JSON schema.
For Sphinx, rather than creating a file to include, the most natural
way to handle this is to have a small custom Sphinx extension which
processes the JSON file and inserts documentation into the rST
file b
rST insists on a blank line before and after a bulleted list,
but our texinfo doc generator did not. Add some extra blank
lines in the doc comments so they're acceptable rST input.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
qapi/block-core.json | 1 +
qapi/char.json
Make the handling of indentation in doc comments more sophisticated,
so that when we see a section like:
Notes: some text
some more text
indented line 3
we save it for the doc-comment processing code as:
some text
some more text
indented line 3
and when we see a section with
The texinfo doc generation doesn't care much about indentation
levels, but we would like to add a rST backend, and rST does care
about indentation.
Make the doc comments more strongly consistent about indentation
for multiline constructs like:
@arg: description line 1
description line 2
Re
A JSON block comment like this:
Returns: nothing on success
If @node is not a valid block device, DeviceNotFound
If @name is not found, GenericError with an explanation
renders like this:
Returns: nothing on success If node is not a valid block device,
DeviceNotFound If nam
We no longer use the generated texinfo format documentation,
so delete the code that generates it, and the test case for
the generation.
Signed-off-by: Peter Maydell
---
Makefile| 1 -
tests/Makefile.include | 15 +-
scripts/qapi-gen.py | 2 -
sc
Add some section headings to the QGA json; this is purely so that we
have some H1 headings, as otherwise each command ends up being
visible in the interop/ manual's table of contents. In an ideal
world there might be a proper 'Introduction' section the way there is
in qapi/qapi-schema.json.
Signe
doc-good.json tests some oddities of markup that we don't want to
accept. Make them match the more restrictive rST syntax:
* in a single list the bullet types must all match
* lists must have leading and following blank lines
* indentation is important
* the '|' example syntax is going to go
There are exactly two places in our json doc comments where we
use the markup accepted by the texi doc generator where a '|' in
the first line of a doc comment means the line should be emitted
as a literal block (fixed-width font, whitespace preserved).
Since we use this syntax so rarely, instead
rST format requires a blank line before the start of a bulleted
or enumerated list. Two places in qapi-schema.json were missing
this blank line.
Some places were using an indented line as a sort of single-item
bulleted list, which in the texinfo output comes out all run
onto a single line; use a r
A handful of QAPI doc comments include lines like
"ppcemb: dropped in 3.1". The doc comment parser will just
put these into whatever the preceding section was; sometimes
that's "Notes", and sometimes it's some random other section,
as with "NetClientDriver" where the "'dump': dropped in 2.12"
line
Convert qemu-ga-ref to rST format. This includes dropping
the plain-text, pdf and info format outputs for this document;
as with all our other Sphinx-based documentation, we provide
HTML and manpage only.
The qemu-ga-ref.rst is somewhat more stripped down than
the .texi was, because we do not (cur
Our current QAPI doc-comment markup allows section headers
(introduced with a leading '=' or '==') anywhere in any documentation
comment. This works for texinfo because the texi generator simply
prints a texinfo heading directive at that point in the output
stream. For rST generation, since we're
Some qapi doc comments have forgotten the ':' after the
@argument, like this:
# @filename Filename for the new image file
# @size Size of the virtual disk in bytes
The result is that these are parsed as part of the body
text and appear as a run-on line:
filename Filename for
A JSON block comment like this:
Returns: nothing on success
If @node is not a valid block device, DeviceNotFound
If @name is not found, GenericError with an explanation
renders like this:
Returns: nothing on success If node is not a valid block device,
DeviceNotFound If nam
A JSON block comment like this:
Returns: nothing on success
If @node is not a valid block device, DeviceNotFound
If @name is not found, GenericError with an explanation
renders like this:
Returns: nothing on success If node is not a valid block device,
D
Avoid texinfo style quoting with `...', because rST treats it
as a syntax error. Use '...' instead, as we do in other
doc comments. This looks OK in texinfo, and rST formats it as
paired-quotation-marks.
Signed-off-by: Peter Maydell
Reviewed-by: Markus Armbruster
---
qapi/ui.json | 24 +
The texinfo doc generation doesn't care much about indentation
levels, but we would like to add a rST backend, and rST does care
about indentation.
Make the doc comments more strongly consistent about indentation
for multiline constructs like:
@arg: description line 1
description line 2
Re
The doc comment for GuestDiskBusType doesn't match up with the
enumeration because of a missing hyphen in 'file-backed-virtual'.
This means the docs are rendered wrongly:
"virtual"
Win virtual bus type "file-backed" virtual: Win file-backed bus type
"file-backed-virtual"
The ascii-art graph in the BlockLatencyHistogramInfo documentation
doesn't render correctly, because the whitespace is collapsed.
Use the '|' format that emits a literal 'example' block so the graph
is displayed correctly.
Strictly the texinfo generated is still wrong because each line
goes into
In the doc comment for input-send-event, there is a multi-line
chunk of text ("The @device...take precedence") which is intended
to be the main body text describing the event. However it has
been placed after the arguments and Returns: section, which
means that the parser actually thinks that this
Fix a typo in the dependency list for the manpages built from the
'interop' manual, which meant we were accidentally not including
the .hx file in the dependency list.
Fixes: e13c59fa4414215500e6
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
---
Makefile | 2 +-
1 file change
There are some stray hardcoded tabs in some of our json files;
remove them.
Signed-off-by: Peter Maydell
Reviewed-by: Markus Armbruster
---
Most of the hardcoded tabs got removed in passing in
fixing the indent in lines that they were in, but
these are not part of doc comments.
---
qapi/block-c
Currently configure's has_sphinx_build() check simply runs a dummy
sphinx-build and either passes or fails. This means that "no
sphinx-build at all" and "sphinx-build exists but is too old" are
both reported the same way.
Further, we want to assume that all the Python we write is running
with at
Currently we insist on using 'sphinx-build' from the $PATH;
allow the user to specify the binary to use. This will be
more useful as we become pickier about the capabilities
we require (eg needing a Python 3 sphinx-build).
Signed-off-by: Peter Maydell
Reviewed-by: Alex Bennée
Reviewed-by: Wainer
This series switches all our QAPI doc comments over from
texinfo format to rST.
Changes v1->v2:
* rebased (a few minor conflicts fixed)
* I have fixed the failures to pass "make check"
* minor tweaks to commit messages etc (noted in individual patches)
* the old patch 12 ('qapi: Explicitly p
On Thu, Feb 13, 2020 at 06:16:46PM +0100, Alberto Garcia wrote:
> I/O requests to encrypted media should be aligned to the sector size
> used by the underlying encryption method, not to BDRV_SECTOR_SIZE.
> Fortunately this doesn't break anything at the moment because
> both existing QCRYPTO_BLOCK_*
Dear All
I am recently using qemu-system-arm to boot a linux uImage.
I would like to do some dynamic instrumentation on the uncompressed kernel.
It seems that I need to focus on two key points.
Firstly, I need to know when the kernel is uncompressed, which means the
compression process is finish
On Wed, 12 Feb 2020 at 21:00, Gerd Hoffmann wrote:
>
> The following changes since commit e18e5501d8ac692d32657a3e1ef545b14e72b730:
>
> Merge remote-tracking branch
> 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20200210' into staging
> (2020-02-10 18:09:14 +)
>
> are available in the Git r
Resizing while migrating is dangerous and does not work as expected.
The whole migration code works on the usable_length of ram blocks and does
not expect this to change at random points in time.
Precopy: The ram block size must not change on the source, after
ram_save_setup(), so as long as the g
I/O requests to encrypted media should be aligned to the sector size
used by the underlying encryption method, not to BDRV_SECTOR_SIZE.
Fortunately this doesn't break anything at the moment because
both existing QCRYPTO_BLOCK_*_SECTOR_SIZE have the same value as
BDRV_SECTOR_SIZE.
The checks in qco
On 13.02.20 17:59, David Hildenbrand wrote:
> On 13.02.20 17:38, Shameerali Kolothum Thodi wrote:
>>
>>
>>> -Original Message-
>>> From: David Hildenbrand [mailto:da...@redhat.com]
>>> Sent: 12 February 2020 18:21
>>> To: Shameerali Kolothum Thodi ;
>>> Igor Mammedov
>>> Cc: peter.mayd...@
On 13.02.20 17:38, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: David Hildenbrand [mailto:da...@redhat.com]
>> Sent: 12 February 2020 18:21
>> To: Shameerali Kolothum Thodi ;
>> Igor Mammedov
>> Cc: peter.mayd...@linaro.org; xiaoguangrong.e...@gmail.com;
>> m...@re
On Tue, Feb 11, 2020 at 07:37:44PM +0100, Andrea Bolognani wrote:
> The current documentation is fairly terse and not easy to decode
> for someone who's not intimately familiar with the inner workings
> of timer devices. Expand on it by providing a somewhat verbose
> description of what behavior ea
> -Original Message-
> From: David Hildenbrand [mailto:da...@redhat.com]
> Sent: 12 February 2020 18:21
> To: Shameerali Kolothum Thodi ;
> Igor Mammedov
> Cc: peter.mayd...@linaro.org; xiaoguangrong.e...@gmail.com;
> m...@redhat.com; shannon.zha...@gmail.com; qemu-devel@nongnu.org;
> xu
On Thu, 13 Feb 2020 at 16:33, Philippe Mathieu-Daudé wrote:
> > * unrealize() must clean up everything realize() creates.
>
> Hmm I guess remember someone once said "only for hot-pluggable objects,
> else don't bother". But then we make a non-hot-pluggable object as
> hot-pluggable and have to fix
Daniel P. Berrangé wrote:
> On Thu, Jan 30, 2020 at 09:03:00AM +0100, Markus Armbruster wrote:
>> Juan Quintela writes:
>>
>> > It will indicate which level use for compression.
>> >
>> > Signed-off-by: Juan Quintela
>>
>> This is slightly confusing (there is no zlib compression), unless you
>
On 2/13/20 3:28 PM, Markus Armbruster wrote:
Eduardo Habkost writes:
On Wed, Feb 12, 2020 at 08:39:55AM +0100, Philippe Mathieu-Daudé wrote:
Cc'ing Eduardo & Markus.
On 2/12/20 7:44 AM, Chenqun (kuhn) wrote:
-Original Message-
From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
Move to system/, as this is mostly about configuring vfio-ap.
Signed-off-by: Cornelia Huck
---
MAINTAINERS | 2 +-
docs/system/index.rst| 1 +
docs/{vfio-ap.txt => system/vfio-ap.rst} | 796 ---
3 files changed, 420 inserti
While at it, also fix the numbering in 'What QEMU does'.
Reviewed-by: Thomas Huth
Signed-off-by: Cornelia Huck
---
MAINTAINERS | 2 +-
docs/devel/index.rst | 1 +
.../{s390-dasd-ipl.txt => s390-dasd-ipl.rst} | 119 +
https://qemu.readthedocs.io/en/latest/index.html collects various
documents from the QEMU docs/ subdirectory; however, none of the
s390 files are currently included. Therefore, I set out to convert
the existing files to rst and hook them up.
s390-dasd-ipl was straightforward enough; I also found a
On Thu, Feb 13, 2020 at 04:24:24PM +0100, Philippe Mathieu-Daudé wrote:
> On 2/13/20 3:39 PM, Peter Maydell wrote:
> > On Thu, 13 Feb 2020 at 14:26, Guenter Roeck wrote:
> > > What really puzzles me is that there is no trace output for
> > > flash data accesses (trace_pflash_data_read and trace_pf
On Fri, 7 Feb 2020 at 08:33, Markus Armbruster wrote:
>
> Peter Maydell writes:
>
> > rST format requires a blank line before the start of a bulleted
> > or enumerated list. Two places in qapi-schema.json were missing
> > this blank line.
> >
> > Some places were using an indented line as a sort
Patchew URL: https://patchew.org/QEMU/20200213074952.544-1-miaoy...@huawei.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#
Its only users are in spapr.c.
Signed-off-by: Greg Kurz
---
I realized just after posting that spapr_reallocate_hpt() didn't need to
be extern anymore. Maybe worth squashing this into the "spapr: Rework
hash<->radix transitions at CAS" patch ?
---
hw/ppc/spapr.c |4 ++--
include/hw/
Typo 'virtuqueue' in subject.
On 2/13/20 3:59 PM, Denis Plotnikov wrote:
v1:
* seg_max default value changing removed
^^^ This part ...
---
The goal is to reduce the amount of requests issued by a guest on
1M reads/writes. This rises the performance up to 4% on that kind of
disk access p
Until the CAS negotiation is over, an HPT can be allocated on three
different paths:
1) during machine reset if the host doesn't support radix,
2) during CAS if the guest wants hash and doesn't support HPT resizing,
in which case we pre-emptively resize the HPT to accomodate maxram,
3) during
On 2/13/20 3:32 PM, Peter Maydell wrote:
On Thu, 13 Feb 2020 at 14:16, Philippe Mathieu-Daudé wrote:
On 2/13/20 2:59 PM, Peter Maydell wrote:
The natural way to implement this is to have the .class_data
be a pointer to a struct which is in an array and defines
relevant per-class stuff, the sam
Markus Armbruster wrote:
> "Dr. David Alan Gilbert" writes:
>
>> * Juan Quintela (quint...@redhat.com) wrote:
>>> Signed-off-by: Juan Quintela
>>> ---
>>> migration/migration.c | 15 +++
>>> monitor/hmp-cmds.c| 4
>>> qapi/migration.json | 29 ++--
On 2020/1/17 0:44, Peter Maydell wrote:
> On Wed, 8 Jan 2020 at 11:33, Dongjiu Geng wrote:
>>
>> Record the GHEB address via fw_cfg file, when recording
>> a error to CPER, it will use this address to find out
>> Generic Error Data Entries and write the error.
>>
>> Make the HEST GHES to a GED dev
Ping ?
This series fixes actual bugs. Also, I have another patch on top of
that to cold plug (or remove) devices pending hot plug (or unplug)
before CAS, hence removing the need for CAS reboot in these cases.
This requires SLOF to correctly parse the FDT it gets at CAS. Patches
have been sent for
On 2/13/20 3:39 PM, Peter Maydell wrote:
On Thu, 13 Feb 2020 at 14:26, Guenter Roeck wrote:
What really puzzles me is that there is no trace output for
flash data accesses (trace_pflash_data_read and trace_pflash_data_write),
meaning the actual flash data access must be handled elsewhere.
Can s
Thank you for your kind advice. I'll try it.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1862167
Title:
Variation of SVE register size (qemu-user-aarch64)
Status in QEMU:
Invalid
Bug descript
On Thu, Feb 13, 2020 at 02:59:37AM +, Liu, Yi L wrote:
> > - Remove the vtd_pasid_as check right below because it's not needed.
> >
> > >
> > >
> > > > > +if (vtd_pasid_as &&
> >
>
> yes, it is. In current series vtd_add_find_pasid_as() doesn’t check th
On Wed, Jan 08, 2020 at 02:54:30AM +0100, V. wrote:
> Hi List,
>
> For my VM setup I tend to use a lot of VM to VM single network links to do
> routing, switching and bridging in VM's instead of the host.
> Also stemming from a silly fetish to sometimes use some OpenBSD VMs as
> firewall, but th
On Thu, Feb 13, 2020 at 09:31:10AM -0500, Peter Xu wrote:
[...]
> > > Apart of this: also I just noticed (when reading the latter part of
> > > the series) that the time that a pasid table walk can consume will
> > > depend on this value too. I'd suggest to make this as small as we
> > > can, as
From: Philippe Mathieu-Daudé
The board revision encode the model type. Add a helper
to extract the model, and use it.
Signed-off-by: Philippe Mathieu-Daudé
Message-id: 20200208165645.15657-12-f4...@amsat.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
hw/arm/raspi.c | 18
From: Philippe Mathieu-Daudé
With the exception of the ignore_memory_transaction_failures
flag set for the raspi2, both machine_class_init() methods
are now identical. Merge them to keep a unique method.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
Message-id: 2020020816564
v1:
* seg_max default value changing removed
---
The goal is to reduce the amount of requests issued by a guest on
1M reads/writes. This rises the performance up to 4% on that kind of
disk access pattern.
The maximum chunk size to be used for the guest disk accessing is
limited with seg_max par
From: Philippe Mathieu-Daudé
raspi_machine_init() access to board_rev via RaspiMachineClass.
raspi2_init() and raspi3_init() do nothing. Call raspi_machine_init
directly.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Igor Mammedov
Message-id: 20200208165645.15657-10-f4...@amsat.org
Signed
From: Philippe Mathieu-Daudé
We added a helper to extract the RAM size from the board
revision, and made board_rev a field of RaspiMachineClass.
The class_init() can now use the helper to extract from the
board revision the board-specific amount of RAM.
Signed-off-by: Philippe Mathieu-Daudé
Mes
101 - 200 of 373 matches
Mail list logo
