Patchew URL: https://patchew.org/QEMU/20190704055150.4899-1-...@kaod.org/
Hi,
This series failed the asan 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 ===
#!/bin/bash
make docker-
+-- On Wed, 3 Jul 2019, no-re...@patchew.org wrote --+
| Patchew URL:
https://patchew.org/QEMU/20190703190615.31436-1-ppan...@redhat.com/
|
| This series failed the asan build test. Please find the testing commands and
| their output below. If you have Docker installed, you can probably reproduce
From: Andrew Jeffery
First up: This is not the way the hardware behaves.
However, it helps resolve real-world problems with short periods being
used under Linux. Commit 4451d3f59f2a ("clocksource/drivers/fttmr010:
Fix set_next_event handler") in Linux fixed the timer driver to
correctly schedule
On 2019/6/24 下午5:18, Peter Xu wrote:
This is an replacement work of Yan Zhao's patch:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg625340.html
vtd_address_space_unmap() will do proper page mask alignment to make
sure each IOTLB message will have correct masks for notification
message
On 2019/6/24 下午5:18, Peter Xu wrote:
From: Yan Zhao
IOMMUNotifier is with inclusive ranges, so we should check
against (VTD_ADDRESS_SIZE(s->aw_bits) - 1).
Signed-off-by: Yan Zhao
[peterx: split from another bigger patch]
Reviewed-by: Eric Auger
Signed-off-by: Peter Xu
---
hw/i386/intel_
On Thursday 04 July 2019 06:42 AM, David Gibson wrote:
> On Wed, Jul 03, 2019 at 02:30:31PM +0530, Aravinda Prasad wrote:
>>
>>
>> On Wednesday 03 July 2019 08:50 AM, David Gibson wrote:
>>> On Tue, Jul 02, 2019 at 04:10:08PM +0530, Aravinda Prasad wrote:
On Tuesday 02 July 2019 0
On Thursday 04 July 2019 06:37 AM, David Gibson wrote:
> On Wed, Jul 03, 2019 at 02:58:24PM +0530, Aravinda Prasad wrote:
>>
>>
>> On Wednesday 03 July 2019 08:33 AM, David Gibson wrote:
>>> On Tue, Jul 02, 2019 at 11:54:26AM +0530, Aravinda Prasad wrote:
On Tuesday 02 July 2019 0
On Thu, Jul 04, 2019 at 01:41:59PM +1000, Suraj Jitindar Singh wrote:
> On Wed, 2019-07-03 at 16:12 +1000, David Gibson wrote:
> > On Mon, Jul 01, 2019 at 04:19:46PM +1000, Suraj Jitindar Singh wrote:
> > > The ibm,get_system_parameter rtas call is used by the guest to
> > > retrieve
> > > data rel
I have clearly been lax in checking my coding style...
I'll fix these, but not until review.
On 7/3/19 9:50 PM, no-re...@patchew.org wrote:
> Patchew URL: https://patchew.org/QEMU/20190703215542.16123-1-js...@redhat.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. Se
> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: Wednesday, July 3, 2019 4:56 PM
> To: Zhang, Chen ; Li Zhijian ;
> Peter Maydell ; Jason Wang
> ; qemu-dev
> Cc: Zhang Chen
> Subject: Re: [Qemu-devel] [PATCH] net/colo-compare.c: Fix memory leak and
On Wed, 2019-07-03 at 16:12 +1000, David Gibson wrote:
> On Mon, Jul 01, 2019 at 04:19:46PM +1000, Suraj Jitindar Singh wrote:
> > The ibm,get_system_parameter rtas call is used by the guest to
> > retrieve
> > data relating to certain parameters of the system. The SPLPAR
> > characteristics option
This assertion should be fixed by upstream commit 8f695676227 "Avoid
assertion in check_interrupts_property()". That should be included in
dtc v1.5.1 which I hope to release soon.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https
Patchew URL: https://patchew.org/QEMU/20190703224707.12437-1-ebl...@redhat.com/
Hi,
This series failed the asan 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 ===
#!/bin/bash
make d
Patchew URL:
https://patchew.org/QEMU/20190703190715.5328-1-jonat...@fintelia.io/
Hi,
This series failed the asan 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 ===
#!/bin/bash
mak
On Wed, Jul 03, 2019 at 12:45:37PM +0200, Auger Eric wrote:
> Hi Peter,
Hi, Eric,
> On 7/3/19 12:21 PM, Peter Xu wrote:
> > On Wed, Jul 03, 2019 at 11:04:38AM +0200, Auger Eric wrote:
> >> Hi Peter,
> >
> > Hi, Eric,
> >
> >>
> >> On 7/3/19 7:41 AM, Peter Xu wrote:
> >>> On Mon, Jul 01, 2019 at
On Wed, Jul 03, 2019 at 02:58:24PM +0530, Aravinda Prasad wrote:
>
>
> On Wednesday 03 July 2019 08:33 AM, David Gibson wrote:
> > On Tue, Jul 02, 2019 at 11:54:26AM +0530, Aravinda Prasad wrote:
> >>
> >>
> >> On Tuesday 02 July 2019 09:21 AM, David Gibson wrote:
> >>> On Wed, Jun 12, 2019 at 02
Patchew URL: https://patchew.org/QEMU/20190703215542.16123-1-js...@redhat.com/
Hi,
This series failed the asan 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 ===
#!/bin/bash
make do
On Wed, Jul 03, 2019 at 02:30:31PM +0530, Aravinda Prasad wrote:
>
>
> On Wednesday 03 July 2019 08:50 AM, David Gibson wrote:
> > On Tue, Jul 02, 2019 at 04:10:08PM +0530, Aravinda Prasad wrote:
> >>
> >>
> >> On Tuesday 02 July 2019 09:41 AM, David Gibson wrote:
> >>> On Wed, Jun 12, 2019 at 02
Patchew URL: https://patchew.org/QEMU/20190703215542.16123-1-js...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH v2 00/18] bitmaps: introduce 'bitmap' sync mode
Message-id: 20190703215542.1
Patchew URL:
https://patchew.org/QEMU/20190703135411.28436-1-berra...@redhat.com/
Hi,
This series failed the asan 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 ===
#!/bin/bash
mak
Patchew URL:
https://patchew.org/QEMU/20190703210821.27550-1-ehabk...@redhat.com/
Hi,
This series failed the asan 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 ===
#!/bin/bash
mak
On Wed, Jul 03, 2019 at 07:50:12PM +0200, Greg Kurz wrote:
> ics_set_kvm_state_one() is called either during reset, in which case
> both 'saved priority' and 'current priority' are equal to 0xff, or
> during migration. In the latter case, 'saved priority' may differ
> from 'current priority' only i
On Wed, Jul 03, 2019 at 07:22:20PM +0200, Greg Kurz wrote:
> The ics_set_kvm_state_one() function is called either to restore the
> state of an interrupt source during migration or to set the interrupt
> source to a default state during reset.
>
> Since always, ie. 2013, the code only sets the MAS
Patchew URL: https://patchew.org/QEMU/20190703190615.31436-1-ppan...@redhat.com/
Hi,
This series failed the asan 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 ===
#!/bin/bash
make
Patchew URL:
https://patchew.org/QEMU/20190703210821.27550-1-ehabk...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PULL v5 00/43] Machine and x86 queue, 2019-07-03
Message-id: 20190703210821.27
Patchew URL:
https://patchew.org/QEMU/20190703163541.19520-1-berra...@redhat.com/
Hi,
This series failed the asan 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 ===
#!/bin/bash
mak
Patchew URL:
https://patchew.org/QEMU/156217621200.562209.8968691631915806468.st...@bahia.lan/
Hi,
This series failed the asan 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 ===
#!
xlsclients has the same output both times.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1834113
Title:
QEMU touchpad input erratic after wakeup from sleep
Status in QEMU:
New
Status in libvirt
Patchew URL:
https://patchew.org/QEMU/156217454083.559957.7359208229523652842.st...@bahia.lan/
Hi,
This series failed the asan 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 ===
#!
Although you generally won't use encryption with a Unix socket (after
all, everything is local, so why waste the CPU power), there are
situations in testsuites where Unix sockets are much nicer than TCP
sockets. Since nbdkit allows encryption over both types of sockets,
it makes sense for qemu-nbd
On Wed, Jul 3, 2019 at 12:07 PM Jonathan Behrens wrote:
>
> Signed-off-by: Jonathan Behrens
>From the text in the spec it sounds like it should be an illegal
instruction exception, at least for now (see below). Maybe it's worth
mentioning in the commit that WFI in U-Mode is allowed if it complet
1. seems like same issue on older intel-microcode.
2. I checked xev on the guest while issue was occuring with the
following results:
when moving the cursor, a buttonpress event is generated along with a
bunch of motionnotify events. After moving it, if I click or touch the
touchpad without movin
Signed-off-by: John Snow
---
tests/qemu-iotests/257 | 409 +++
tests/qemu-iotests/257.out | 2199
tests/qemu-iotests/group |1 +
3 files changed, 2609 insertions(+)
create mode 100755 tests/qemu-iotests/257
create mode 100644 tests/qemu-iotest
On Mon, 1 Jul 2019 at 05:43, Jan Bobek wrote:
>
> Add an x86 configuration file with all MMX instructions.
>
> Signed-off-by: Jan Bobek
> --- /dev/null
> +++ b/x86.risu
> @@ -0,0 +1,96 @@
> +###
> +# Copyright (c) 2019 L
Because the new-style python tests don't use the iotests.main() test
launcher, we don't turn on the debugger logging for these scripts
when invoked via ./check -d.
Refactor the launcher shim into new and old style shims so that they
share environmental configuration.
Two cleanup notes: debug was
Cascadelake-Server-v2 had stepping=5 set by mistake (I misread an
old patch setting stepping=5 at compat_props), and doesn't have
mds-no set. Fix these two issues.
Reported-by: Xiaoyao Li
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
run_job can cancel pending jobs to simulate failure. This lets us use
the pending callback to issue test commands while the job is open, but
then still have the job fail in the end.
Signed-off-by: John Snow
---
tests/qemu-iotests/iotests.py | 22 --
1 file changed, 20 inserti
I'm surprised it didn't come up sooner, but sometimes we have a +busy
bitmap as a source. This is dangerous from the QMP API, but if we are
the owner that marked the bitmap busy, it's safe to merge it using it as
a read only source.
It is not safe in the general case to allow users to read from in
Seems that it comes up enough.
Signed-off-by: John Snow
---
tests/qemu-iotests/040| 6 +-
tests/qemu-iotests/093| 6 ++
tests/qemu-iotests/139| 7 ++-
tests/qemu-iotests/238| 5 +
tests/qemu-iotests/iotests.py | 4
5 files changed, 10 insertio
Nobody calls the function like this currently, but we neither prohibit
or cope with this behavior. I decided to make the function cope with it.
Signed-off-by: John Snow
---
util/hbitmap.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/util/hbitmap.c b/util/hbi
On Tue, 2 Jul 2019 at 17:35, Aleksandar Markovic
wrote:
>
> From: Aleksandar Markovic
>
> The following changes since commit d247c8e7f4fc856abf799c37ca9818514ddb08b7:
>
> Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190701' into
> staging (2019-07-02 11:48:39 +0100)
>
> are availa
Add a public interface for get. While we're at it,
rename "bdrv_get_dirty_bitmap_locked" to "bdrv_dirty_bitmap_get_locked".
(There are more functions to rename to the bdrv_dirty_bitmap_VERB form,
but they will wait until the conclusion of this series.)
Signed-off-by: John Snow
---
block/dirty-b
This adds a "never" policy for bitmap synchronization. Regardless of if
the job succeeds or fails, we never update the bitmap. This can be used
to perform differential backups, or simply to avoid the job modifying a
bitmap.
Signed-off-by: John Snow
---
block/backup.c | 5 +++--
qapi/block-
Patchew URL: https://patchew.org/QEMU/20190703171005.26231-1-phi...@redhat.com/
Hi,
This series failed the asan 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 ===
#!/bin/bash
make d
This simplifies some interface matters; namely the initialization and
(later) merging the manifest back into the sync_bitmap if it was
provided.
Signed-off-by: John Snow
---
block/backup.c | 76 --
1 file changed, 37 insertions(+), 39 deletions(-)
Use "FilePaths" instead of "FilePath" to request multiple files be
cleaned up after we leave that object's scope.
This is not crucial; but it saves a little typing.
Signed-off-by: John Snow
---
tests/qemu-iotests/iotests.py | 33 ++---
1 file changed, 22 insertions(+
Daniel P. Berrangé writes:
> A supposed exploit of QEMU was recently announced as CVE-2019-12928
> claiming that the monitor console was insecure because the "migrate"
> comand enabled arbitrary command execution for a remote attacker.
>
> For this to be a flaw the user launching QEMU must have
With the "never" sync policy, we actually can utilize readonly bitmaps
now. Loosen the check at the QMP level, and tighten it based on
provided arguments down at the job creation level instead.
Signed-off-by: John Snow
---
block/backup.c | 6 ++
blockdev.c | 2 +-
2 files changed, 7 inse
Create a common core that comprises the actual meat of what the backup API
boundary needs to do, and then switch drive-backup to use it.
Questions:
- do_drive_backup now acquires and releases the aio_context in addition
to do_backup_common doing the same. Can I drop this from drive_backup?
Sig
This adds an "always" policy for bitmap synchronization. Regardless of if
the job succeeds or fails, the bitmap is *always* synchronized. This means
that for backups that fail part-way through, the bitmap retains a record of
which sectors need to be copied out to accomplish a new backup using the
o
Signed-off-by: John Snow
---
blockdev.c | 73 +++---
1 file changed, 3 insertions(+), 70 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 5fd663a7e5..cad300d526 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3638,82 +3638,15 @@ XDbgBlockGraph
Signed-off-by: John Snow
---
util/hbitmap.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/util/hbitmap.c b/util/hbitmap.c
index 3b6acae42b..306bc4876d 100644
--- a/util/hbitmap.c
+++ b/util/hbitmap.c
@@ -777,7 +777,27 @@ void hbitmap_trun
This series adds a new "BITMAP" sync mode that is meant to replace the
existing "INCREMENTAL" sync mode.
This mode can have its behavior modified by issuing any of three bitmap sync
modes, passed as arguments to the job.
The three bitmap sync modes are:
- CONDITIONAL: This is an alias for the old
On 7/1/19 6:35 AM, Jan Bobek wrote:
> +MOVQMMX 011 d 1110 !emit { rex(w => 1); modrm(mod
> => MOD_DIRECT, rm => ~REG_ESP); }
> +MOVQ_memMMX 011 d 1110 !emit { rex(w => 1); modrm(mod
> => ~MOD_DIRECT); mem(size => 8); }
Oh, note that there are only 8
We don't need or want a new sync mode for simple differences in
semantics. Create a new mode simply named "BITMAP" that is designed to
make use of the new Bitmap Sync Mode field.
Because the only bitmap mode is 'conditional', this adds no new
functionality to the backup job (yet). The old increme
drive-backup and blockdev-backup have an awful lot of things in common
that are the same. Let's fix that.
I don't deduplicate 'target', because the semantics actually did change
between each structure. Leave that one alone so it can be documented
separately.
Signed-off-by: John Snow
---
qapi/bl
On 7/1/19 6:35 AM, Jan Bobek wrote:
> Add an x86 configuration file with all MMX instructions.
>
> Signed-off-by: Jan Bobek
> ---
> x86.risu | 96
> 1 file changed, 96 insertions(+)
> create mode 100644 x86.risu
Note that most of these M
Patchew URL:
https://patchew.org/QEMU/20190703155244.28166-1-alex.ben...@linaro.org/
Hi,
This series failed the asan 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 ===
#!/bin/bash
Depending on what a user is trying to accomplish, there might be a few
bitmap cleanup actions that occur when an operation is finished that
could be useful.
I am proposing three:
- NEVER: The bitmap is never synchronized against what was copied.
- ALWAYS: The bitmap is always synchronized, even on
>Core Gen8 Mobile
That's my i9-8950HK.
What I don't understand is why it works perfectly on the host but not on
the guest. And the fact that it persists even when rebooting the guest
implies it's not an issue with the guest runtime or anything. It seems
like the issue must be with the way qemu is
Hi,
Just wanted to follow up to see what your thoughts are. Is it preferable
if I submit a PR to the Go runtime first? That would mitigate concerns
about Go breaking on QEMU with this patch.
Thanks,
Marli
On Mon, Jul 1, 2019 at 3:04 PM Marlies Ruck wrote:
> Hi All,
>
> You are correct, this
Add support for registration of multiple versions of CPU models.
The existing CPU models will be registered with a "-v1" suffix.
The -noTSX, -IBRS, and -IBPB CPU model variants will become
versions of the original models in a separate patch, so
make sure we register no versions for them.
Signed-
The old CPU models will be just aliases for specific versions of
the original CPU models.
Signed-off-by: Eduardo Habkost
Message-Id: <20190628002844.24894-7-ehabk...@redhat.com>
Reviewed-by: Daniel P. Berrangé
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 601 ++---
Document that CPU model runnability guarantees won't apply to
unversioned CPU models anymore.
Signed-off-by: Eduardo Habkost
Message-Id: <20190628002844.24894-9-ehabk...@redhat.com>
Reviewed-by: Daniel P. Berrangé
Signed-off-by: Eduardo Habkost
---
qemu-deprecated.texi | 19 +++
From: Igor Mammedov
it will test preferred memdev option more extensively and remove
undesired deprecation warnings during 'make check'
Signed-off-by: Igor Mammedov
Message-Id: <20190702140745.27767-3-imamm...@redhat.com>
[ehabkost: remove numa-test.c changes]
Signed-off-by: Eduardo Habkost
--
From: Igor Mammedov
QEMU fails to start if memory-less node is present when memdev
is used
qemu-system-x86_64 -object memory-backend-ram,id=ram0,size=128M \
-numa node -numa node,memdev=ram0
with error:
"memdev option must be specified for either all or no nodes"
which w
This will help us avoid spurious warnings during "make check".
Note that this will silence the warnings generated by
tests/numa-test, but not the ones generated by
tests/bios-tables-test. We still need to change
tests/bios-tables-test to use "-numa ...,memdev=" to silence
these warnings.
Signed-
Add versions of CPU models that are equivalent to their -IBRS,
-noTSX and -IBRS variants.
The separate variants will eventually be removed and become
aliases for these CPU versions.
Signed-off-by: Eduardo Habkost
Message-Id: <20190628002844.24894-6-ehabk...@redhat.com>
Reviewed-by: Daniel P. Ber
When introducing versioned CPU models, the string at
X86CPUDefinition::model_id might not be the model-id we'll really
use. Instantiate a CPU object and check the model-id property on
"-cpu help"
Signed-off-by: Eduardo Habkost
Message-Id: <20190628002844.24894-4-ehabk...@redhat.com>
Reviewed-by:
Export machine type deprecation status through the query-machines
QMP command. With this, libvirt and management software will be
able to show this information to users and/or suggest changes to
VM configuration to avoid deprecated machines.
Signed-off-by: Eduardo Habkost
Message-Id: <2019060823
Add new version of Cascadelake-Server CPU model, setting
stepping=5 and enabling the IA32_ARCH_CAPABILITIES MSR
with some flags.
The new feature will introduce a new host software requirement,
breaking our CPU model runnability promises. This means we can't
enable the new CPU model version by def
From: Like Xu
To make smp_parse() more flexible and expansive, a smp_parse function
pointer is added to MachineClass that machine types could override.
The generic smp_parse() code in vl.c is moved to hw/core/machine.c, and
become the default implementation of MachineClass::smp_parse. A PC-speci
Add a new option that can be used to disable feature flag
filtering. This will allow CPU model compatibility test cases to
work without host hardware dependencies.
Signed-off-by: Eduardo Habkost
Message-Id: <20190628002844.24894-3-ehabk...@redhat.com>
Reviewed-by: Daniel P. Berrangé
Signed-off-
From: Like Xu
For PC target, users could configure the number of dies per one package
via command line with this patch, such as "-smp dies=2,cores=4".
The parsing rules of new cpu-topology model obey the same restrictions/logic
as the legacy socket/core/thread model especially on missing values
From: Roman Kagan
X86CPU.hv-spinlocks is a uint32 property that has a special setter
validating the value to be no less than 0xFFF and no bigger than
UINT_MAX. The latter check is redundant; as for the former, there
appears to be no reason to prohibit the user from setting it to a lower
value.
Management software will be expected to resolve CPU model name
aliases using the new field.
Signed-off-by: Eduardo Habkost
Message-Id: <20190628002844.24894-2-ehabk...@redhat.com>
Reviewed-by: Daniel P. Berrangé
Signed-off-by: Eduardo Habkost
---
qapi/machine-target.json | 9 -
1 file
This will make unversioned CPU models behavior depend on the
machine type:
* "pc-*-4.0" and older will not report them as aliases.
This is done to keep compatibility with older QEMU versions
after management software starts translating aliases.
* "pc-*-4.1" will translate unversioned CPU mode
From: Like Xu
The CPUID.1F as Intel V2 Extended Topology Enumeration Leaf would be
exposed if guests want to emulate multiple software-visible die within
each package. Per Intel's SDM, the 0x1f is a superset of 0xb, thus they
can be generated by almost same code as 0xb except die_offset setting.
From: Igor Mammedov
Legacy '-numa node,mem' option has a number of issues and mgmt often
defaults to it. Unfortunately it's no possible to replace it with
an alternative '-numa memdev' without breaking migration compatibility.
What's possible though is to deprecate it, keeping option working with
On 03/07/19 18:40, Montes, Julio wrote:
> On Wed, 2019-07-03 at 18:21 +0200, Paolo Bonzini wrote:
>> On 03/07/19 17:49, Julio Montes wrote:
>>> In pc_init1(), ISA IDE is initialized without checking if ISAPC or
>>> IDE_ISA
>>> configs are enabled. This results in a link error when
>>> CONFIG_ISAPC
From: Paul Lai
SnowRidge CPU supports Accelerator Infrastrcture Architecture (MOVDIRI,
MOVDIR64B), CLDEMOTE and SPLIT_LOCK_DISABLE.
MOVDIRI, MOVDIR64B, and CLDEMOTE are found via CPUID.
The availability of SPLIT_LOCK_DISABLE is check via msr access
References can be found in either:
https://so
The current default value for hv-spinlocks is 0x (meaning
"never retry"). However, the value is stored as a signed
integer, making the getter of the hv-spinlocks QOM property
return -1 instead of 0x.
Fix this by changing the type of X86CPU::hyperv_spinlock_attempts
to uint32_t. T
From: Igor Mammedov
The parameter allows to configure fake NUMA topology where guest
VM simulates NUMA topology but not actually getting performance
benefits from it. The same or better results could be achieved
using 'memdev' parameter.
Beside of unpredictable performance, '-numa node.mem' optio
The variable is completely unused, probably a leftover from
previous code clean up.
Signed-off-by: Eduardo Habkost
Message-Id: <20190625050008.12789-3-ehabk...@redhat.com>
Reviewed-by: Dr. David Alan Gilbert
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 6 --
1 file changed, 6 del
hppa_cpu_list() is dead code and is never called. Delete it.
Cc: Richard Henderson
Reviewed-by: Igor Mammedov
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Eduardo Habkost
Message-Id: <20190517191332.23400-1-ehabk...@redhat.com>
Acked-by: Richard Hender
From: Igor Mammedov
Fallback might affect guest or worse whole host performance
or functionality if backing file were used to share guest RAM
with another process.
Patch deprecates fallback so that we could remove it in future
and ensure that QEMU will provide expected behavior and fail if
it ca
From: Igor Mammedov
Implicit RAM distribution between nodes has exactly the same issues as:
"numa: deprecate 'mem' parameter of '-numa node' option"
only with QEMU being the user that's 'adding' 'mem' parameter.
Deprecate it, to get it out of the way so that we could consolidate
guest RAM allo
From: Wei Yang
Use the same definition as features/user_features in CPUX86State.
Signed-off-by: Wei Yang
Message-Id: <20190620023746.9869-1-richardw.y...@linux.intel.com>
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t
From: Like Xu
In new sockets/dies/cores/threads model, the apicid of logical cpu could
imply die level info of guest cpu topology thus x86_apicid_from_cpu_idx()
need to be refactored with #dies value, so does apicid_*_offset().
To keep semantic compatibility, the legacy pkg_offset which helps to
If cpu->host_phys_bits_limit is set, QEMU will make
cpu->phys_bits be lower than host_phys_bits on some cases. This
triggers a warning that was supposed to be printed only if
phys-bits was explicitly set in the command-line.
Reorder the code so the value of cpu->phys_bits is validated
before the
From: Igor Mammedov
QEMU will crash when device-memory-region-size property is read if
ms->device_memory
wasn't initialized yet.
Crash can be reproduced with:
$QEMU -preconfig -qmp unix:qmp_socket,server,nowait &
./scripts/qmp/qom-get -s qmp_socket /machine.device-memory-region-size
Instead
From: Alex Bennée
Commit 2d384d7c8 broken the build when built with:
configure --without-default-devices --disable-user
The reason was the conversion of cpu->hyperv_synic to
cpu->hyperv_synic_kvm_only although the rest of the patch introduces a
feature checking mechanism. So I've fixed the KV
From: Like Xu
The field die_id (default as 0) and has_die_id are introduced to X86CPU.
Following the legacy smp check rules, the die_id validity is added to
the same contexts as leagcy smp variables such as hmp_hotpluggable_cpus(),
machine_set_cpu_numa_node(), cpu_slot_to_string() and pc_cpu_pre_
From: Like Xu
The global smp variables in arm are replaced with smp machine properties.
The init_cpus() and *_create_rpu() are refactored to pass MachineState.
A local variable of the same name would be introduced in the declaration
phase if it's used widely in the context OR replace it on the s
From: Like Xu
The die-level as the first PC-specific cpu topology is added to the leagcy
cpu topology model, which has one die per package implicitly and only the
numbers of sockets/cores/threads are configurable.
In the new model with die-level support, the total number of logical
processors (i
From: Like Xu
To support multiple dies configuration on PCMachine, the best place to
set CPUX86State->nr_dies with requested PCMachineState->smp_dies is in
pc_new_cpu() and pc_cpu_pre_plug(). Refactoring pc_new_cpu() is applied
and redundant parameter "const char *typename" would be removed.
Sug
From: Like Xu
The global smp variables in vl.c are completely replaced with machine
properties.
Form this commit, the smp_cpus/smp_cores/smp_threads/max_cpus are deprecated
and only machine properties within MachineState are fully applied and enabled.
Signed-off-by: Like Xu
Reviewed-by: Alist
From: Like Xu
The global smp variables in alpha/hppa/mips/openrisc/sparc*/xtensa codes
are replaced with smp properties from MachineState.
A local variable of the same name would be introduced in the declaration
phase if it's used widely in the context OR replace it on the spot if it's
only used
From: Like Xu
To get rid of the global smp_* variables we're currently using, it's recommended
to pass MachineState in the list of incoming parameters for functions that use
global smp variables, thus some redundant parameters are dropped. It's applied
for legacy smbios_*(), *_machine_reset(), ho
From: Like Xu
The global smp variables in i386 are replaced with smp machine properties.
To avoid calling qdev_get_machine() as much as possible, some related funtions
for acpi data generations are refactored. No semantic changes.
A local variable of the same name would be introduced in the decl
1 - 100 of 392 matches
Mail list logo
