When integrating the crypto support with qcow/qcow2, we don't
want to use the bare LUKS option names "hash-alg", "key-secret",
etc. We need to namespace them to match the nested QAPI schema.
e.g. "encrypt.hash-alg", "encrypt.key-secret"
so that they don't clash with any general qcow options at a
Instead of requiring separate input/output buffers for
encrypting data, change encrypt_sectors() to assume
use of a single buffer, encrypting in place. One current
caller uses the same buffer for input/output already
and the other two callers are easily converted to do so.
Reviewed-by: Alberto Gar
Historically the qcow & qcow2 image formats supported a property
"encryption=on" to enable their built-in AES encryption. We'll
soon be supporting LUKS for qcow2, so need a more general purpose
way to enable encryption, with a choice of formats.
This introduces an "encrypt.format" option, which wi
Document that use of guest virtual sector numbers as the basis for
the initialization vectors is a potential weakness, when combined
with internal snapshots or multiple images using the same passphrase.
This fixes the formatting of the itemized list too.
Reviewed-by: Max Reitz
Reviewed-by: Albert
Previously posted:
v1: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00201.html
v2: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05147.html
v3: https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg05671.html
v4: https://lists.gnu.org/archive/html/qemu-devel/2017-02/m
On 14 June 2017 at 08:51, Gerd Hoffmann wrote:
> Hi,
>
> Here is the usb patch queue with two bugfixes.
>
> please pull,
> Gerd
>
> The following changes since commit 475df9d809b1f3a7ebe8b15abd208216591f0143:
>
> Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
>
The qcow driver refuses to open images which are less than
2 bytes in size, but will happily create such images. Add
a check in the create path to avoid this discrepancy.
Reviewed-by: Max Reitz
Reviewed-by: Alberto Garcia
Reviewed-by: Eric Blake
Signed-off-by: Daniel P. Berrange
---
block/qco
Test 042 is designed to verify operation with zero sized images.
Such images are not supported with qcow (v1), so this test has
always failed.
Reviewed-by: Max Reitz
Reviewed-by: Alberto Garcia
Signed-off-by: Daniel P. Berrange
---
tests/qemu-iotests/042 | 2 +-
1 file changed, 1 insertion(+),
The block/crypto.c defines a set of QemuOpts that provide
parameters for encryption. This will also be needed by
the qcow/qcow2 integration, so expose the relevant pieces
in a new block/crypto.h header. Some helper methods taking
QemuOpts are changed to take QDict to simplify usage in
other places.
On 06/19/17 18:57, Mark Cave-Ayland wrote:
> On 19/06/17 15:28, Eduardo Habkost wrote:
>
>> On Mon, Jun 19, 2017 at 01:59:07PM +0100, Mark Cave-Ayland wrote:
>>> In preparation for calling fw_cfg_init1() during realize rather than during
>>> init, move the assert() checking for existing fw_cfg dev
edu.c seems not to contain any target-specific code, so we can
put it into common-obj-y to compile it only once for all targets.
Signed-off-by: Thomas Huth
---
hw/misc/Makefile.objs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
Commit c783b0012708 ("ppc: Rework CPU compatibility testing across
migration") added a subsection to the vmstate description of CPUs.
This subsection is sent when the CPU compat_pvr field is non-zero,
which is likely to happen after CAS negociation (since QEMU 2.9) or
even before CAS negociation if
On 19/06/17 15:28, Eduardo Habkost wrote:
> On Mon, Jun 19, 2017 at 01:59:07PM +0100, Mark Cave-Ayland wrote:
>> In preparation for calling fw_cfg_init1() during realize rather than during
>> init, move the assert() checking for existing fw_cfg devices and the linking
>> of the device to the machi
On 19 June 2017 at 16:26, Juan Quintela wrote:
> Fam Zheng wrote:
>> Previously, dst side will immediately try to lock the write byte upon
>> receiving QEMU_VM_EOF, but at src side, bdrv_inactivate_all() is only
>> done after sending it. If the src host is under load, dst may fail to
>> acquire t
On 18/06/2017 21:11, Sergio Andres Gomez Del Real wrote:
> This patch simply replaces the separate boolean field in CPUState that
> kvm, hax (and upcoming hvf) have for keeping track of vcpu dirtiness
> with a single shared field.
>
> Signed-off-by: Sergio Andres Gomez Del Real
> ---
> include
On Mon, Jun 19, 2017 at 08:49:39PM +0800, Peter Xu wrote:
> Introduce this new field for the accelerator instances so that each
> specific accelerator in the future can register its own global
> properties to be used further by the system. It works just like how the
> old machine compatible proper
On Mon, Jun 19, 2017 at 08:49:41PM +0800, Peter Xu wrote:
> Let KVM be the first user of the new AccelState.global_props field.
> Basically kvm accel only contains accel props for TYPE_X86_CPUs but not
> anything else yet.
>
> There will be a change on how these global properties are applied for
>
Peter Xu wrote:
> v3 contains too much new things. So here comes a new cover letter with
> richer information.
>
> The main goal of this series is to let MigrationState be a QDev.
>
> It helps in many use cases.
Hi
I haven't reviewed the qdev part of the patches (it is a landmine for
me). But I
Peter Xu wrote:
> Move it into MigrationState, revert its meaning and renaming it to
> send_section_footer, with a property bound to it. Same trick is played
> like previous patches.
>
> Removing savevm_skip_section_footers().
>
> Signed-off-by: Peter Xu
Reviewed-by: Juan Quintela
Peter Xu wrote:
> It was in SaveState but now moved to MigrationState altogether, reverted
> its meaning, then renamed to "send_configuration". Again, using
> HW_COMPAT_2_3 for old PC/SPAPR machines, and accel_register_prop() for
> xen_init().
>
> Removing savevm_skip_configuration().
>
> Signed-o
Peter Xu wrote:
> One less global variable, and it does only matter with migration.
>
> We keep the old "--only-migratable" option, but also now we support:
>
> -global migration.only-migratable=true
>
> Currently still keep the old interface.
>
> Hmm, now vl.c has no way to access migrate_get_c
Peter Xu wrote:
> Put it into MigrationState then we can use the properties to specify
> whether to enable storing global state.
>
> Removing global_state_set_optional() since now we can use HW_COMPAT_2_3
> for x86/power, and accel_register_prop() for xen_init().
>
Reviewed-by: Juan Quintela
On Mon, Jun 19, 2017 at 04:27:53PM +0100, Peter Maydell wrote:
> On 19 June 2017 at 15:49, Daniel P. Berrange wrote:
> > IIUC as well as fixing the race condition, you're also improving
> > error reporting by using qemu_file_set_error() which was not done
> > previously. Would be nice to mention t
On 19 June 2017 at 15:49, Daniel P. Berrange wrote:
> IIUC as well as fixing the race condition, you're also improving
> error reporting by using qemu_file_set_error() which was not done
> previously. Would be nice to mention that in the commit message
> too if you respin for any other reason, but
Fam Zheng wrote:
> Previously, dst side will immediately try to lock the write byte upon
> receiving QEMU_VM_EOF, but at src side, bdrv_inactivate_all() is only
> done after sending it. If the src host is under load, dst may fail to
> acquire the lock due to racing with the src unlocking it.
>
> F
On Fri, Jun 16, 2017 at 07:36:45PM +0200, Kevin Wolf wrote:
> The qed block driver is one of the last remaining block drivers that use the
> AIO callback style interfaces. This series converts it to the coroutine model
> that other drivers are using and removes some AIO functions from the block
> l
On Mon, Jun 19, 2017 at 08:49:37PM +0800, Peter Xu wrote:
> Originally it can only alloc new entries and insert. Let it be smarter
> that it can update existing fields, and even delete elements. This is
> preparation of (finally) the replacement of x86_cpu_apply_props(). If
> you see x86_cpu_apply_
On 06/19/2017 01:08 AM, Thomas Huth wrote:
+/* Sanity check the function code and storage characteristic. */
+if (fc > 1 || sc > 3) {
+if (!s390_has_feat(S390_FEAT_COMPARE_AND_SWAP_AND_STORE_2)) {
+goto spec_exception;
+}
+if (fc > 2 || sc > 4 || (fc =
On 2017-06-19 17:00, Stefan Hajnoczi wrote:
> It's confusing when two different variables have the same name in one
> function.
>
> Cc: Reda Sallahi
> Signed-off-by: Stefan Hajnoczi
> ---
> qemu-img.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/qemu-img.c
On Tue, Jun 13, 2017 at 10:20:51PM +0200, Max Reitz wrote:
> === Series dependencies ===
>
> This series depends on v7 of Stefan's series
> "qemu-img: add measure sub-command"
> (http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg03035.html).
>
>
> === Actual cover letter ===
>
> This s
It's confusing when two different variables have the same name in one
function.
Cc: Reda Sallahi
Signed-off-by: Stefan Hajnoczi
---
qemu-img.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index 0ad698d..c285c2f 100644
--- a/qemu-img.c
+++
On 2017-06-19 15:55, Kevin Wolf wrote:
> Am 14.06.2017 um 17:31 hat Max Reitz geschrieben:
>> This generic function (along with its implementations for different
>> types) determines whether two QObjects are equal.
>>
>> Signed-off-by: Max Reitz
>
>> diff --git a/qobject/qdict.c b/qobject/qdict.c
On 06/19/17 16:28, Eduardo Habkost wrote:
> On Mon, Jun 19, 2017 at 01:59:07PM +0100, Mark Cave-Ayland wrote:
>> In preparation for calling fw_cfg_init1() during realize rather than during
>> init, move the assert() checking for existing fw_cfg devices and the linking
>> of the device to the machin
On Sat, Jun 17, 2017 at 12:06:58AM +0800, Fam Zheng wrote:
> Previously, dst side will immediately try to lock the write byte upon
> receiving QEMU_VM_EOF, but at src side, bdrv_inactivate_all() is only
> done after sending it. If the src host is under load, dst may fail to
> acquire the lock due t
On Sun, May 28, 2017 at 04:06:49PM +0300, Dan Aloni wrote:
> The number of queues that should be return by the admin command should:
>
> 1) Only mention the number of non-admin queues.
> 2) It is zero-based, meaning that '0 == one non-admin queue',
> '1 == two non-admin queues', and so fo
Signed-off-by: Tobias Schramm
---
v4: Use OPT_NUMBER for file mode arguments, fix back to front naming,
fix resource leak and add sanity checking for fmode/dmode arguments
v3: Use unsigned types for umask
v2: Adjust patch to QEMU code style
fsdev/file-op-9p.h | 4
fsdev/qemu-f
Hi,
i've noticed that there is no way to control the permissions of newly created
files and
folders on the host when using 9p in mapped security mode. This can be a big
problem when
configuring permissions for access to such data for groups and via ACLs on the
host.
Thus I added the options fmo
On Mon, Jun 19, 2017 at 01:59:07PM +0100, Mark Cave-Ayland wrote:
> In preparation for calling fw_cfg_init1() during realize rather than during
> init, move the assert() checking for existing fw_cfg devices and the linking
> of the device to the machine with object_property_add_child() to a new
> f
On 19/06/2017 14:49, Peter Xu wrote:
> We have HW_COMPAT_*, however that's only binded to machines, not other
> things (like accelerators). Behind it, it was register_compat_prop()
> that played the trick. Let's export the function for further use
> outside HW_COMPAT_* magic.
>
> Meanwhile, move
Am 14.06.2017 um 17:31 hat Max Reitz geschrieben:
> Signed-off-by: Max Reitz
Reviewed-by: Kevin Wolf
Am 14.06.2017 um 17:31 hat Max Reitz geschrieben:
> Currently, bdrv_reopen_prepare() assumes that all BDS options are
> strings. However, this is not the case if the BDS has been created
> through the json: pseudo-protocol or blockdev-add.
>
> Note that the user-invokable reopen command is an HMP
On Mon, Jun 19, 2017 at 01:59:05PM +0100, Mark Cave-Ayland wrote:
> As indicated by Laszlo it is a QOM bug for the realize() method to actually
> map the device. Set up the IO regions within fw_cfg_io_realize() and defer
> the mapping with sysbus_add_io() to the caller, as already done in
> fw_cfg_
On Mon, Jun 19, 2017 at 01:59:06PM +0100, Mark Cave-Ayland wrote:
> The setting of the FW_CFG_VERSION_DMA bit is the same across both the
> TYPE_FW_CFG_MEM and TYPE_FW_CFG_IO devices, so unify the logic in
> fw_cfg_init1().
>
> Signed-off-by: Mark Cave-Ayland
> Reviewed-by: Laszlo Ersek
> Tested
AcpiEventStatusBits defines bits in a bitmask. Having it in decimal
notation is rather uncommon. Make it more clear which bits are meant
there.
No functional change.
Signed-off-by: Christian Ludwig
---
include/hw/acpi/acpi_dev_interface.h | 10 +-
1 file changed, 5 insertions(+), 5 dele
When the guest unplugs the emulated NICs, call net_cleanup() to cleanup
the network infrastructure in QEMU as it is not needed anymore. Most
importantly, this allows the tap interfaces which QEMU holds open to be
closed and removed.
Signed-off-by: Ross Lagerwall
---
hw/i386/xen/xen_platform.c |
On Wed, Jun 07, 2017 at 07:38:44PM +0200, Max Reitz wrote:
> On 2017-06-01 19:27, Daniel P. Berrange wrote:
> > Currently 'qemu-img info' reports a simple "encrypted: yes"
> > field. This is not very useful now that qcow2 can support
> > multiple encryption formats. Users want to know which format
On Wed, Jun 07, 2017 at 07:19:28PM +0200, Max Reitz wrote:
> On 2017-06-01 19:27, Daniel P. Berrange wrote:
> > This adds support for using LUKS as an encryption format
> > with the qcow2 file, using the new encrypt.format parameter
> > to request "luks" format. e.g.
> >
> > # qemu-img create --
On Wed, Jun 07, 2017 at 06:55:39PM +0200, Max Reitz wrote:
> On 2017-06-01 19:27, Daniel P. Berrange wrote:
> > This converts the qcow driver to make use of the QCryptoBlock
> > APIs for encrypting image content. This is only wired up to
> > permit use of the legacy QCow encryption format. Users wh
David Gibson wrote on 06/18/2017 04:04:48
AM:
> On Fri, Jun 16, 2017 at 11:31:02AM -0500, alar...@ddci.com wrote:
> > I haven't received any feedback on this patch, ... Did it get lost?
>
> No, I've just been busy and then sick. I'll get to it eventually..
As always, thanks for your efforts.
On Wed, Jun 07, 2017 at 06:40:32PM +0200, Max Reitz wrote:
> On 2017-06-01 19:27, Daniel P. Berrange wrote:
> > Historically the qcow & qcow2 image formats supported a property
> > "encryption=on" to enable their built-in AES encryption. We'll
> > soon be supporting LUKS for qcow2, so need a more g
Am 14.06.2017 um 17:31 hat Max Reitz geschrieben:
> This generic function (along with its implementations for different
> types) determines whether two QObjects are equal.
>
> Signed-off-by: Max Reitz
> diff --git a/qobject/qdict.c b/qobject/qdict.c
> index 88e2ecd..2ed57ca 100644
> --- a/qobjec
Qcow2COWRegion has two attributes:
- The offset of the COW region from the start of the first cluster
touched by the I/O request. Since it's always going to be positive
and the maximum request size is at most INT_MAX, we can use a
regular unsigned int to store this offset.
- The size of the
This patch splits do_perform_cow() into three separate functions to
read, encrypt and write the COW regions.
perform_cow() can now read both regions first, then encrypt them and
finally write them to disk. The memory allocation is also done in
this function now, using one single buffer large enoug
Instead of calling perform_cow() twice with a different COW region
each time, call it just once and make perform_cow() handle both
regions.
This patch simply moves code around. The next one will do the actual
reordering of the COW operations.
Signed-off-by: Alberto Garcia
Reviewed-by: Eric Blake
Hi all,
here's a patch series that rewrites the copy-on-write code in the
qcow2 driver to reduce the number of I/O operations.
This is version v4, please refer to the original e-mail for a complete
description:
https://lists.gnu.org/archive/html/qemu-block/2017-05/msg00882.html
Regards,
Berto
Reading both COW regions requires two separate requests, but it's
perfectly possible to merge them and perform only one. This generally
improves performance, particularly on rotating disk drives. The
downside is that the data in the middle region is read but discarded.
This patch takes a conservat
We are using the return value of qcow2_encrypt_sectors() to detect
problems but we are throwing away the returned Error since we have no
way to report it to the user. Therefore we can simply get rid of the
local Error variable and pass NULL instead.
Alternatively we could try to figure out a way t
Instead of passing a single buffer pointer to do_perform_cow_write(),
pass a QEMUIOVector. This will allow us to merge the write requests
for the COW regions and the actual data into a single one.
Although do_perform_cow_read() does not strictly need to change its
API, we're doing it here as well
If the guest tries to write data that results on the allocation of a
new cluster, instead of writing the guest data first and then the data
from the COW regions, write everything together using one single I/O
operation.
This can improve the write performance by 25% or more, depending on
several fa
On 06/19/2017 09:40 AM, Marcel Apfelbaum wrote:
On 16/06/2017 16:53, Igor Mammedov wrote:
On Wed, 14 Jun 2017 19:27:12 -0500
Michael Roth wrote:
Quoting Igor Mammedov (2017-06-14 04:00:01)
On Tue, 13 Jun 2017 16:42:45 -0500
Michael Roth wrote:
Quoting Igor Mammedov (2017-06-09 03:27:33)
On Mon, Jun 19, 2017 at 10:43:51AM +0100, Peter Maydell wrote:
> On 19 June 2017 at 09:48, Dr. David Alan Gilbert wrote:
> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> >> On Thu, Jun 15, 2017 at 01:14:15PM +0100, Dr. David Alan Gilbert wrote:
> >> > * Eduardo Habkost (ehabk...@redhat.com) wr
Am 14.06.2017 um 17:30 hat Max Reitz geschrieben:
> Signed-off-by: Max Reitz
Reviewed-by: Kevin Wolf
On Thu, 8 Jun 2017 15:09:30 +1000
David Gibson wrote:
> There are substantial differences in the various paths through
> set_isolation_state(), both for setting to ISOLATED versus UNISOLATED
> state and for logical versus physical DRCs.
>
> So, split the set_isolation_state() method into isolat
This patch factor out the duplicate qmp throttle interface code
that was present in both block and fsdev device files.
Signed-off-by: Pradeep Jagadeesh
---
blockdev.c | 53 +++-
hmp.c | 21 ++-
include/qem
This patch introduces hmp interfaces for the fsdev
throttle functionality
Signed-off-by: Pradeep Jagadeesh
---
hmp-commands-info.hx | 18 ++
hmp-commands.hx | 19 +++
hmp.c| 66
hmp.h
This patch enables qmp interfaces for the fsdev
devices. This provides two interfaces one
for querying info of all the fsdev devices. The second one
to set the IO limits for the required fsdev device.
Signed-off-by: Pradeep Jagadeesh
---
Makefile| 3 ++
fsdev/qemu-fsdev-dum
These patches provide the qmp interface, to query the io throttle
status of the all fsdev devices that are present in a vm.
also, it provides an interface to set the io throttle parameters of a
fsdev to a required value. some of the patches also remove the duplicate
code that was present in block
This patch enables qmp interfaces for the fsdev
devices. This provides two interfaces one
for querying info of all the fsdev devices. The second one
to set the IO limits for the required fsdev device.
Signed-off-by: Pradeep Jagadeesh
Reviewed-by: Greg Kurz
Reviewed-by: Eric Blake
---
qapi/bl
This patch factor out the duplicate throttle code that was present in
block and fsdev devices.
Signed-off-by: Pradeep Jagadeesh
---
blockdev.c | 44 +---
fsdev/qemu-fsdev-throttle.c | 43 +--
fsdev/qemu-fsde
When looking to instantiate a TYPE_FW_CFG_MEM or TYPE_FW_CFG_IO device to be
able to wire it up differently, it is much more convenient for the caller to
instantiate the device and have the fw_cfg default files already preloaded
during realize.
Move fw_cfg_init1() to the end of both the fw_cfg_mem
The setting of the FW_CFG_VERSION_DMA bit is the same across both the
TYPE_FW_CFG_MEM and TYPE_FW_CFG_IO devices, so unify the logic in
fw_cfg_init1().
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Laszlo Ersek
Tested-by: Laszlo Ersek
---
hw/nvram/fw_cfg.c | 16 +++-
1 file change
On 06/19/2017 02:52 PM, David Hildenbrand wrote:
> On 19.06.2017 14:47, Christian Borntraeger wrote:
>> On 06/19/2017 02:41 PM, David Hildenbrand wrote:
>>> On 19.06.2017 14:33, Christian Borntraeger wrote:
On 06/19/2017 02:05 PM, David Hildenbrand wrote:
> On 19.06.2017 12:03, David Hilde
As part of some ongoing sun4u work, I need to be able to wire the fw_cfg
IO interface to a separate IO space by instantiating the qdev device instead
of calling fw_cfg_init_io(). This patchset brings FW_CFG_IO in line with
FW_CFG_MEM and tidies up the realize methods accordingly.
Signed-off-by: Ma
By exposing FWCfgIoState and FWCfgMemState internals we allow the possibility
for the internal MemoryRegion fields to be mapped by name for boards that wish
to wire up the fw_cfg device themselves.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Laszlo Ersek
Tested-by: Laszlo Ersek
---
hw/nvram/f
It was in SaveState but now moved to MigrationState altogether, reverted
its meaning, then renamed to "send_configuration". Again, using
HW_COMPAT_2_3 for old PC/SPAPR machines, and accel_register_prop() for
xen_init().
Removing savevm_skip_configuration().
Signed-off-by: Peter Xu
---
hw/i386/p
In preparation for calling fw_cfg_init1() during realize rather than during
init, move the assert() checking for existing fw_cfg devices and the linking
of the device to the machine with object_property_add_child() to a new
fw_cfg instance_init() function.
This guarantees that we will still assert
As indicated by Laszlo it is a QOM bug for the realize() method to actually
map the device. Set up the IO regions within fw_cfg_io_realize() and defer
the mapping with sysbus_add_io() to the caller, as already done in
fw_cfg_init_mem_wide().
This makes the iobase and dma_iobase properties now obso
Move it into MigrationState, revert its meaning and renaming it to
send_section_footer, with a property bound to it. Same trick is played
like previous patches.
Removing savevm_skip_section_footers().
Signed-off-by: Peter Xu
---
hw/i386/pc_piix.c| 1 -
hw/ppc/spapr.c | 1 -
One less global variable, and it does only matter with migration.
We keep the old "--only-migratable" option, but also now we support:
-global migration.only-migratable=true
Currently still keep the old interface.
Hmm, now vl.c has no way to access migrate_get_current(). Export a
function for
On 19.06.2017 14:47, Christian Borntraeger wrote:
> On 06/19/2017 02:41 PM, David Hildenbrand wrote:
>> On 19.06.2017 14:33, Christian Borntraeger wrote:
>>> On 06/19/2017 02:05 PM, David Hildenbrand wrote:
On 19.06.2017 12:03, David Hildenbrand wrote:
> On 15.06.2017 22:37, Richard Hender
Let the old man "MigrationState" join the object family. Direct benefit
is that we can start to use all the property features derived from
current QDev, like: HW_COMPAT_* bits, command line setup for migration
parameters (so will never need to set them up each time using HMP/QMP,
this is really, re
Put it into MigrationState then we can use the properties to specify
whether to enable storing global state.
Removing global_state_set_optional() since now we can use HW_COMPAT_2_3
for x86/power, and accel_register_prop() for xen_init().
Signed-off-by: Peter Xu
---
hw/i386/pc_piix.c
Am 15.06.2017 um 18:38 hat Stefan Hajnoczi geschrieben:
> This series extends qemu-iotests 068 to also run with iothread enabled. Doing
> so was harder than expected because:
>
> 1. ioeventfd is disabled without -M accel=kvm even though it should work
> 2. loadvm still has an iothread bug
>
> In
Trace global property applying. Now there are machine compat properties,
accel compat properties, and user specified global properties. It
provides a way to trace those properties that really applied.
Signed-off-by: Peter Xu
---
Makefile.objs | 1 +
hw/core/qdev-properties.c | 2 ++
Let KVM be the first user of the new AccelState.global_props field.
Basically kvm accel only contains accel props for TYPE_X86_CPUs but not
anything else yet.
There will be a change on how these global properties are applied for
TYPE_X86_CPU devices. The general workflow of the global property stu
Let tcg use the new AccelState.global_props as well (used similar trick
for the kvm convertion in previous patch). Basically we are moving the
tcg_default_props into tcg codes, and link these compat properties onto
newly created AccelState.global_props.
This is much simpler than KVM.
Signed-off-b
Introduce this new field for the accelerator instances so that each
specific accelerator in the future can register its own global
properties to be used further by the system. It works just like how the
old machine compatible properties do, but only tailored for
accelerators.
Use the newly export
After previous patch to let qdev_prop_register_global_list() use
register_compat_prop(), then caller won't be guaranteed that the
GlobalProperty pointer passed in will be the one linked to global_props
list (now we always alloc new GlobalProperty for it). So prop->used will
never be set.
Let's avo
It works very similar to register_compat_prop() but does not need a
malloc, however mostly all the callers of it are doing malloc on their
own. Then it makes little sense to keep it.
Replacing all the callers with register_compat_prop(), meanwhile adding
one more parameter "user_provided" for it t
v3 contains too much new things. So here comes a new cover letter with
richer information.
The main goal of this series is to let MigrationState be a QDev.
It helps in many use cases.
First of all, we can remove many legacy tricky functions. To name
some: savevm_skip_section_footers(), savevm_sk
Originally it can only alloc new entries and insert. Let it be smarter
that it can update existing fields, and even delete elements. This is
preparation of (finally) the replacement of x86_cpu_apply_props(). If
you see x86_cpu_apply_props(), it allows to skip entries when value is
NULL. Here, it wo
We have HW_COMPAT_*, however that's only binded to machines, not other
things (like accelerators). Behind it, it was register_compat_prop()
that played the trick. Let's export the function for further use
outside HW_COMPAT_* magic.
Meanwhile, move it to qdev-properties.c where seems more proper.
On 06/19/2017 02:41 PM, David Hildenbrand wrote:
> On 19.06.2017 14:33, Christian Borntraeger wrote:
>> On 06/19/2017 02:05 PM, David Hildenbrand wrote:
>>> On 19.06.2017 12:03, David Hildenbrand wrote:
On 15.06.2017 22:37, Richard Henderson wrote:
> There are no uses in a Linux system wit
Am 15.06.2017 um 18:38 hat Stefan Hajnoczi geschrieben:
> Avoid duplicating the QEMU command-line.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> tests/qemu-iotests/068 | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/tests/qemu-iotests/068 b/tests/qemu-iotests
On 19/06/17 09:57, Laszlo Ersek wrote:
> On 06/18/17 22:23, Michael S. Tsirkin wrote:
>> On Sun, Jun 18, 2017 at 09:02:14AM +0100, Mark Cave-Ayland wrote:
>>> By exposing FWCfgIoState and FWCfgMemState internals we allow the
>>> possibility
>>> for the internal MemoryRegion fields to be mapped by
On 19.06.2017 14:33, Christian Borntraeger wrote:
> On 06/19/2017 02:05 PM, David Hildenbrand wrote:
>> On 19.06.2017 12:03, David Hildenbrand wrote:
>>> On 15.06.2017 22:37, Richard Henderson wrote:
There are no uses in a Linux system with which to test,
but it Looks Right by my reading
On 16/06/2017 16:53, Igor Mammedov wrote:
On Wed, 14 Jun 2017 19:27:12 -0500
Michael Roth wrote:
Quoting Igor Mammedov (2017-06-14 04:00:01)
On Tue, 13 Jun 2017 16:42:45 -0500
Michael Roth wrote:
Quoting Igor Mammedov (2017-06-09 03:27:33)
[...]
But that raises a 2nd point. Our dile
On 18/06/17 21:23, Michael S. Tsirkin wrote:
> On Sun, Jun 18, 2017 at 09:02:14AM +0100, Mark Cave-Ayland wrote:
>> By exposing FWCfgIoState and FWCfgMemState internals we allow the possibility
>> for the internal MemoryRegion fields to be mapped by name for boards that
>> wish
>> to wire up the
On 06/19/2017 02:05 PM, David Hildenbrand wrote:
> On 19.06.2017 12:03, David Hildenbrand wrote:
>> On 15.06.2017 22:37, Richard Henderson wrote:
>>> There are no uses in a Linux system with which to test,
>>> but it Looks Right by my reading of the PoO.
>>
>> I am using next.git/master with this p
On 15.06.2017 19:38, Stefan Hajnoczi wrote:
This series extends qemu-iotests 068 to also run with iothread enabled. Doing
so was harder than expected because:
1. ioeventfd is disabled without -M accel=kvm even though it should work
2. loadvm still has an iothread bug
Instead of adding a ./chec
101 - 200 of 270 matches
Mail list logo
