Daniel P. Berrangé writes:
> On Mon, Jul 08, 2019 at 12:27:12PM +0200, Philippe Mathieu-Daudé wrote:
[...]
>> Anyway, to stop bikeshedding this thread, can you add few lines about
>> why not use getenv() in the HACKING?
>
> I don't actually think the getenv thing is a security issue in any case.
Peter Maydell writes:
> On Sun, 7 Jul 2019 at 21:26, Stefan Weil wrote:
>> This is a general problem all over the QEMU code. I usually compile with
>> nearly all warnings enabled and get now lots of errors with the latest
>> code and after updating to gcc-8.3.0 (Debian buster). It should be
>>
Stefan Weil writes:
> Am 08.07.19 um 06:40 schrieb Markus Armbruster:
>
[...]
>> However, the gnu_ in gnu_scanf tells the compiler we're linking with the
>> GNU C Library, which seems unwise. Hmm, we already use gnu_printf.
>> Commit 9c9e7d51bf0:
>>
>> Newer gcc versions support format
On Fri, Jul 05, 2019 at 07:01:42PM +0800, Liu Yi L wrote:
> +static bool vtd_process_pasid_desc(IntelIOMMUState *s,
> + VTDInvDesc *inv_desc)
> +{
> +if ((inv_desc->val[0] & VTD_INV_DESC_PASIDC_RSVD_VAL0) ||
> +(inv_desc->val[1] &
Denverton-Server is the Atom Processor of Intel Harrisonville platform.
For more information:
https://ark.intel.com/content/www/us/en/ark/products/\
codename/63508/denverton.html
Signed-off-by: Tao Xu
---
target/i386/cpu.c | 45 +
1 file changed, 45
Public bug reported:
$ qemu-system-mips --version
QEMU emulator version 4.0.50 (v4.0.0-1975-gf34edbc760)
$ qemu-system-mips -machine malta -bios /dev/null -nodefaults -monitor stdio -S
(qemu) o 0xaf00 0
qemu-system-mips: hw/acpi/cpu.c:197: cpu_hotplug_hw_init: Assertion
Patchew URL:
https://patchew.org/QEMU/1562637554-22439-1-git-send-email-kwankh...@nvidia.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 ===
Patchew URL:
https://patchew.org/QEMU/1562637554-22439-1-git-send-email-kwankh...@nvidia.com/
Hi,
This series failed build test on s390x host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to
Define flags to be used as delimeter in migration file stream.
Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
region from these functions at source during saving or pre-copy phase.
Set VFIO device state depending on VM's state. During live migration, VM is
running when
VM state change handler gets called on change in VM's state. This is used to set
VFIO device state to _RUNNING.
VM state change handler, migration state change handler and log_sync listener
are called asynchronously, which sometimes lead to data corruption in migration
region. Initialised mutex
This function is used in follwing patch in this series.
Migration region is mmaped when migration starts and will be unmapped when
migration is complete.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/common.c | 20
hw/vfio/trace-events
- Migration functions are implemented for VFIO_DEVICE_TYPE_PCI device in this
patch series.
- VFIO device supports migration or not is decided based of migration region
query. If migration region query is successful and migration region
initialization is successful then migration is
Flow during _RESUMING device state:
- If Vendor driver defines mappable region, mmap migration region.
- Load config state.
- For data packet, till VFIO_MIG_FLAG_END_OF_STATE is not reached
- read data_size from packet, read buffer of data_size
- read data_offset from where QEMU should
Hook vfio_get_object callback for PCI devices.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
Suggested-by: Cornelia Huck
---
hw/vfio/pci.c | 8
include/hw/vfio/vfio-common.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index
Added migration state change notifier to get notification on migration state
change. These states are translated to VFIO device state and conveyed to vendor
driver.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/migration.c | 54
Call vfio_migration_probe() and vfio_migration_finalize() functions for
vfio-pci device to enable migration for vfio PCI device.
Removed vfio_pci_vmstate structure.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/pci.c | 15 +--
1 file changed, 9 insertions(+), 6
vfio_listerner_log_sync gets list of dirty pages from vendor driver and mark
those pages dirty when in _SAVING state.
Return early for the RAM block section of mapped MMIO region.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/common.c | 35 +++
These functions save and restore PCI device specific data - config
space of PCI device.
Tested save and restore with MSI and MSIX type.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/pci.c | 114 ++
- Defined MIGRATION region type and sub-type.
- Used 3 bits to define VFIO device states.
Bit 0 => _RUNNING
Bit 1 => _SAVING
Bit 2 => _RESUMING
Combination of these bits defines VFIO device's state during migration
_STOPPED => All bits 0 indicates VFIO device stopped.
Dirty page tracking (.log_sync) is part of RAM copying state, where
vendor driver provides the bitmap of pages which are dirtied by vendor
driver through migration region and as part of RAM copy, those pages
gets copied to file stream.
To get dirty page bitmap:
- write start address, page_size
Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
functions. These functions handles pre-copy and stop-and-copy phase.
In _SAVING|_RUNNING device state or pre-copy phase:
- read pending_bytes
- read data_offset - indicates kernel driver to write data to staging
buffer
Add migration support for VFIO device
This Patch set include patches as below:
- Define KABI for VFIO device for migration support.
- Added save and restore functions for PCI configuration space
- Generic migration functionality for VFIO device.
* This patch set adds functionality only for PCI
On Thu, 2019-07-04 at 14:59 +1000, David Gibson wrote:
> 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
On Fri, Jul 05, 2019 at 07:01:36PM +0800, Liu Yi L wrote:
> +void pci_setup_pasid_ops(PCIDevice *dev, PCIPASIDOps *ops)
> +{
> +assert(ops && !dev->pasid_ops);
> +dev->pasid_ops = ops;
> +}
> +
> +bool pci_device_is_ops_set(PCIBus *bus, int32_t devfn)
Name should be
On Fri, Jul 05, 2019 at 07:01:38PM +0800, Liu Yi L wrote:
> This patch adds vfio implementation PCIPASIDOps.alloc_pasid/free_pasid().
> These two functions are used to propagate guest pasid allocation and
> free requests to host via vfio container ioctl.
>
> Cc: Kevin Tian
> Cc: Jacob Pan
> Cc:
On Fri, Jul 05, 2019 at 07:01:39PM +0800, Liu Yi L wrote:
> This patch adds virtual command support to Intel vIOMMU per Intel VT-d 3.1
> spec. This patch adds two virtual commands: alloc_pasid and free_pasid.
>
> Cc: Kevin Tian
> Cc: Jacob Pan
> Cc: Peter Xu
> Cc: Yi Sun
> Signed-off-by: Liu
On Fri, Jul 05, 2019 at 07:01:37PM +0800, Liu Yi L wrote:
> Intel VT-d 3.0 introduces scalable mode, and it has a bunch of
> capabilities related to scalable mode translation, thus there
> are multiple combinations. While this vIOMMU implementation
> wants simplify it for user by providing typical
On Fri, Jul 05, 2019 at 07:01:35PM +0800, Liu Yi L wrote:
> This patch imports the vIOMMU related definitions from kernel
> uapi/vfio.h. e.g. pasid allocation, guest pasid bind, guest pasid
> table bind and guest iommu cache invalidation.
>
> Cc: Kevin Tian
> Cc: Jacob Pan
> Cc: Peter Xu
> Cc:
On Fri, Jul 5, 2019 at 6:43 AM Stefano Garzarella wrote:
>
> On Fri, Jul 05, 2019 at 11:58:43AM +0200, Max Reitz wrote:
> > On 05.07.19 11:32, Stefano Garzarella wrote:
> > > This patch allows 'qemu-img info' to show the 'disk size' for
> > > the RBD images that have the fast-diff feature
On 7/8/2019 9:20 PM, Eric Blake wrote:
On 7/7/19 9:29 AM, Tao Xu wrote:
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
On 7/8/2019 5:09 PM, Igor Mammedov wrote:
On Tue, 2 Jul 2019 16:50:24 +0800
Tao Xu wrote:
On 7/1/2019 7:25 PM, Igor Mammedov wrote:
On Fri, 14 Jun 2019 23:56:24 +0800
Tao Xu wrote:
...
@@ -2710,6 +2711,8 @@ void acpi_build(AcpiBuildTables *tables, MachineState
*machine)
Ok, I'll add it to my to do list then
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1835827
Title:
HTIF symbols no longer recognized by RISC-V spike board
Status in QEMU:
New
Bug description:
On Mon, Jun 24, 2019 at 01:22:07PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Wed, Jun 19, 2019 at 10:10:40PM +0200, Markus Armbruster wrote:
> >> Suggested-by: Paolo Bonzini
> >> Cc: Eduardo Habkost
> >> Cc: Marcel Apfelbaum
> >> Signed-off-by: Markus Armbruster
>
Hey Klaus,
Sorry for the late reply! I finally found this message amid the pile of
emails Qemu dumped on me.
I don't know what the right answer is here... NVMe is designed in a way
where you *do* "carve up" the flash into logical groupings and the nvme
firmware decides on how that's done.
Public bug reported:
We just ran into an issue with the Perl package on Debian/m68k when
being built with qemu-user [1].
The problem can be boiled down to qemu-user always reporting absolute
paths for the shell variable $0 no matter on how the command was
invoked.
A simple reproducer is this:
No, patch sign-off requires a legal name.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1835827
Title:
HTIF symbols no longer recognized by RISC-V spike board
Status in QEMU:
New
Bug
> On 8 Jul 2019, at 21:21, Jan Kiszka wrote:
>
> On 21.06.19 13:30, Paolo Bonzini wrote:
>> From: Liran Alon
>
> This broke bisection (which I currently have to do because this pull manages
> to
> lock up 5.1 host kernels): cpu_has_nested_virt will only come later in this
> series.
>
>
On Thu, Jul 04, 2019 at 09:33:22AM +0200, Igor Mammedov wrote:
> On Wed, 3 Jul 2019 16:37:02 -0300
> Eduardo Habkost wrote:
> > [...]
> > > +TestData data = { .ram_size = 128 };
> > >
> > > -if (strcmp(arch, "aarch64") == 0) {
> > > -args = "-machine virt";
> > > +if
Patchew URL:
https://patchew.org/QEMU/1562613452-24969-1-git-send-email-kwankh...@nvidia.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 ===
It is used to do transactional movement of the bitmap (which is
possible in conjunction with merge command). Transactional bitmap
movement is needed in scenarios with external snapshot, when we don't
want to leave copy of the bitmap in the base image.
Signed-off-by: Vladimir Sementsov-Ogievskiy
From: Vladimir Sementsov-Ogievskiy
Test persistent bitmap copying with and without removal of original
bitmap.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: John Snow
---
tests/qemu-iotests/254 | 30 +-
tests/qemu-iotests/254.out | 82
From: Vladimir Sementsov-Ogievskiy
Commit 0a6c86d024c52 returned these locks back to add/remove
functionality, to protect from intersection of persistent bitmap
related IO with other IO. But other bitmap-related functions called
here are unrelated to the problem, and there are no needs to keep
Hi, this is a proposal based off of Vladimir's patchset:
[Qemu-devel] [PATCH 0/4] qapi: block-dirty-bitmap-remove transaction action
===
V3:
===
001/3:[] [--] 'blockdev: reduce aio_context locked sections in bitmap
add/remove'
002/3:[0024] [FC] 'qapi: implement block-dirty-bitmap-remove
Hi Markus;
recently it's come up a few times that it might be nice to hide bitmaps
that have no names from the query results, because these are "internal"
bitmaps used by QEMU that the user cannot manipulate.
Actually, all of the bitmap-finding functions will refuse to touch
bitmaps with no
On Sat, Jul 06, 2019 at 12:07:50AM +0200, Paolo Bonzini wrote:
> On 05/07/19 23:41, Eduardo Habkost wrote:
> +for (i = 0; i < ARRAY_SIZE(feature_dependencies); i++) {
> +FeatureDep *d = _dependencies[i];
> +if ((env->user_features[d->from] & d->from_flag) &&
>
Currently is not possible to use a file that is part of a read-only
filesystem as memory backend for nvdimm devices, even if this is not modified
in the guest. In order to improve the security of Virtual Machines that share
and do not modify the memory-backend-file, QEMU should support
read-only
I think you are right. Would you like to write a patch to fix the issue?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1835827
Title:
HTIF symbols no longer recognized by RISC-V spike board
On 7/8/19 2:33 PM, Max Reitz wrote:
> On 08.07.19 20:24, John Snow wrote:
>>
>>
>> On 7/8/19 7:44 AM, Max Reitz wrote:
>>> On 05.07.19 18:45, John Snow wrote:
On 7/4/19 12:49 PM, Max Reitz wrote:
> On 03.07.19 23:55, John Snow wrote:
>>>
>>> [...]
>>>
>> +
>> +/**
Public bug reported:
Tested commit: f34edbc760b0f689deddd175fc08732ecb46665f
I belive this was introduced in 0ac24d56c5e7d32423ea78ac58a06b444d1df04d
when the spike's load_kernel() was moved to riscv_load_kernel() which no
longer included htif_symbol_callback().
** Affects: qemu
On Fri, Jul 5, 2019 at 8:51 AM Philippe Mathieu-Daudé wrote:
>
> A "system reset" sets the device state machine in READ_ARRAY mode
> and, after some delay, set the SR.7 READY bit.
>
> We do not model timings, so we set the SR.7 bit directly.
>
> The TYPE_DEVICE interface provides a DeviceReset
Hi
On Mon, Jul 8, 2019 at 8:40 PM Peter Maydell wrote:
>
> On Mon, 7 Jan 2019 at 12:23, Marc-André Lureau
> wrote:
> >
> > Generalize machine compatibility properties
> >
> > During "[PATCH v2 05/10] qom/globals: generalize
> >
Patchew URL:
https://patchew.org/QEMU/1562613452-24969-1-git-send-email-kwankh...@nvidia.com/
Hi,
This series failed build test on s390x host. Please find the details below.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
# Testing script will be invoked under the git checkout with
# HEAD pointing to
Since merge 31ed41889e6e13699871040fe089a2884dca46cb ("Merge
remote-tracking branch
'remotes/elmarco/tags/machine-props-pull-request' into staging"), the
compat arrays are in lowercase.
Signed-off-by: Marc-André Lureau
---
docs/devel/migration.rst | 2 +-
hw/i386/pc_piix.c| 2 +-
2
On Mon, Jul 08, 2019 at 04:56:56PM +0200, Laurent Desnogues wrote:
> Hi,
>
> On Sat, Jul 6, 2019 at 12:40 AM Eduardo Habkost wrote:
> >
> > From: Like Xu
> >
> > The global smp variables in vl.c are completely replaced with machine
> > properties.
> >
> > Form this commit, the
"git archive" fails when a submodule has a modification, because "git
stash create" doesn't handle submodules. Let's teach our
archive-source.sh to handle modifications in submodules the same way
as qemu tree, by creating a stash.
Signed-off-by: Marc-André Lureau
---
scripts/archive-source.sh |
> ...this is the list of warnings for target/mips/translate.c:
> /home/debian/src/github/qemu/qemu/target/mips/translate.c:10047:13: warning:
> this statement may fall through [-Wimplicit-fallthrough=]
> /home/debian/src/github/qemu/qemu/target/mips/translate.c:10056:13: warning:
> this
Flow during _RESUMING device state:
- If Vendor driver defines mappable region, mmap migration region.
- Load config state.
- For data packet, till VFIO_MIG_FLAG_END_OF_STATE is not reached
- read data_size from packet, read buffer of data_size
- read data_offset from where QEMU should
Call vfio_migration_probe() and vfio_migration_finalize() functions for
vfio-pci device to enable migration for vfio PCI device.
Removed vfio_pci_vmstate structure.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/pci.c | 15 +--
1 file changed, 9 insertions(+), 6
Added migration state change notifier to get notification on migration state
change. These states are translated to VFIO device state and conveyed to vendor
driver.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/migration.c | 54
vfio_listerner_log_sync gets list of dirty pages from vendor driver and mark
those pages dirty when in _SAVING state.
Return early for the RAM block section of mapped MMIO region.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/common.c | 35 +++
- Migration functions are implemented for VFIO_DEVICE_TYPE_PCI device in this
patch series.
- VFIO device supports migration or not is decided based of migration region
query. If migration region query is successful and migration region
initialization is successful then migration is
VM state change handler gets called on change in VM's state. This is used to set
VFIO device state to _RUNNING.
VM state change handler, migration state change handler and log_sync listener
are called asynchronously, which sometimes lead to data corruption in migration
region. Initialised mutex
Dirty page tracking (.log_sync) is part of RAM copying state, where
vendor driver provides the bitmap of pages which are dirtied by vendor
driver through migration region and as part of RAM copy, those pages
gets copied to file stream.
To get dirty page bitmap:
- write start address, page_size
Hook vfio_get_object callback for PCI devices.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
Suggested-by: Cornelia Huck
---
hw/vfio/pci.c | 8
include/hw/vfio/vfio-common.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index
Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
functions. These functions handles pre-copy and stop-and-copy phase.
In _SAVING|_RUNNING device state or pre-copy phase:
- read pending_bytes
- read data_offset - indicates kernel driver to write data to staging
buffer
These functions save and restore PCI device specific data - config
space of PCI device.
Tested save and restore with MSI and MSIX type.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/pci.c | 114 ++
Define flags to be used as delimeter in migration file stream.
Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
region from these functions at source during saving or pre-copy phase.
Set VFIO device state depending on VM's state. During live migration, VM is
running when
- Defined MIGRATION region type and sub-type.
- Used 3 bits to define VFIO device states.
Bit 0 => _RUNNING
Bit 1 => _SAVING
Bit 2 => _RESUMING
Combination of these bits defines VFIO device's state during migration
_STOPPED => All bits 0 indicates VFIO device stopped.
This function is used in follwing patch in this series.
Migration region is mmaped when migration starts and will be unmapped when
migration is complete.
Signed-off-by: Kirti Wankhede
Reviewed-by: Neo Jia
---
hw/vfio/common.c | 20
hw/vfio/trace-events
Add migration support for VFIO device
This Patch set include patches as below:
- Define KABI for VFIO device for migration support.
- Added save and restore functions for PCI configuration space
- Generic migration functionality for VFIO device.
* This patch set adds functionality only for PCI
On 7/8/19 11:51 AM, Kevin Wolf wrote:
> Am 05.07.2019 um 17:28 hat Eric Blake geschrieben:
>> Commit b76b4f60 allowed '-o compat=v3' as an alias for the
>> less-appealing '-o compat=1.1' for 'qemu-img create' since we want to
>> use the QMP form as much as possible, but forgot to do likewise for
On 7/8/19 2:47 PM, Eric Blake wrote:
> A recent tweak to the '-o help' output for qemu-img needs to be
> reflected into the iotests expected outputs.
>
> Fixes: f7077c98
> Reported-by: Kevin Wolf
> Signed-off-by: Eric Blake
Reviewed-by: John Snow
> ---
>
> 'git grep -l "0.10 or 1.1"
At some point vmxnet3 live migration stopped working and git-bisect
didn't help finding a working version.
The issue is the PCI configuration space is not being migrated
successfully and MSIX remains masked at destination.
Remove the migration differentiation between PCI and PCIe since
the logic
* Dmitry Fleytman (dmitry.fleyt...@gmail.com) wrote:
>
>
> > On 8 Jul 2019, at 19:03, Dr. David Alan Gilbert wrote:
> >
> > * Marcel Apfelbaum (marcel.apfelb...@gmail.com) wrote:
> >>
> >>
> >>> On 7/5/19 2:14 PM, Sukrit Bhatnagar wrote:
> On Fri, 5 Jul 2019 at 16:29, Dmitry Fleytman
> On 8 Jul 2019, at 19:03, Dr. David Alan Gilbert wrote:
>
> * Marcel Apfelbaum (marcel.apfelb...@gmail.com) wrote:
>>
>>
>>> On 7/5/19 2:14 PM, Sukrit Bhatnagar wrote:
On Fri, 5 Jul 2019 at 16:29, Dmitry Fleytman
wrote:
> On 5 Jul 2019, at 4:07, Marcel Apfelbaum
On 7/8/19 12:38 PM, Daniel P. Berrangé wrote:
On Sat, Jul 06, 2019 at 10:04:55PM +0300, Marcel Apfelbaum wrote:
Hi Sukrit,
On 7/6/19 7:09 AM, Sukrit Bhatnagar wrote:
Changes in v2:
* Modify load_dsr() such that dsr mapping is not performed if dsr value
is non-NULL. Also move
If the user hasn't specified a firmware to load (with -bios) or
specified no bios (with -bios none) then load OpenSBI by default. This
allows users to boot a RISC-V kernel with just -kernel.
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
hw/riscv/boot.c
Add OpenSBI version 0.4 as a git submodule and as a prebult binary.
OpenSBI (https://github.com/riscv/opensbi) aims to provide an open-source
reference implementation of the RISC-V Supervisor Binary Interface (SBI)
specifications for platform-specific firmwares executing in M-mode. For all
This series includes the OpenSBI firmware for QEMU RISC-V users.
To avoid breakages we have not changed the default behaviour of QEMU.
The plan is to change the default though, which is why an entry to the
qemu-deprecated.texi file has been added as well as a new warning.
After this series QEMU
On 08.07.19 20:31, Jan Kiszka wrote:
>
> On 21.06.19 13:30, Paolo Bonzini wrote:
>> From: Liran Alon
>>
>> Previous commits have added support for migration of nested virtualization
>> workloads. This was done by utilising two new KVM capabilities:
>> KVM_CAP_NESTED_STATE and
A recent tweak to the '-o help' output for qemu-img needs to be
reflected into the iotests expected outputs.
Fixes: f7077c98
Reported-by: Kevin Wolf
Signed-off-by: Eric Blake
---
'git grep -l "0.10 or 1.1" tests' confirms this was the only
output file affected
tests/qemu-iotests/082.out | 54
On 7/8/19 7:03 PM, Dr. David Alan Gilbert wrote:
* Marcel Apfelbaum (marcel.apfelb...@gmail.com) wrote:
On 7/5/19 2:14 PM, Sukrit Bhatnagar wrote:
On Fri, 5 Jul 2019 at 16:29, Dmitry Fleytman wrote:
On 5 Jul 2019, at 4:07, Marcel Apfelbaum wrote:
At some point vmxnet3 live migration
On 08.07.19 20:32, John Snow wrote:
>
>
> On 7/8/19 8:02 AM, Max Reitz wrote:
>> On 05.07.19 18:52, John Snow wrote:
>>>
>>>
>>> On 7/4/19 1:29 PM, Max Reitz wrote:
>>
>> [...]
>>
Which brings me to a question: Why is the copy bitmap assigned to the
target in the first place? Wouldn’t
On 08.07.19 20:24, John Snow wrote:
>
>
> On 7/8/19 7:44 AM, Max Reitz wrote:
>> On 05.07.19 18:45, John Snow wrote:
>>>
>>>
>>> On 7/4/19 12:49 PM, Max Reitz wrote:
On 03.07.19 23:55, John Snow wrote:
>>
>> [...]
>>
> +
> +/**
> + * bdrv_dirty_bitmap_merge_internal: merge src
On 7/8/19 8:02 AM, Max Reitz wrote:
> On 05.07.19 18:52, John Snow wrote:
>>
>>
>> On 7/4/19 1:29 PM, Max Reitz wrote:
>
> [...]
>
>>> Which brings me to a question: Why is the copy bitmap assigned to the
>>> target in the first place? Wouldn’t it make more sense on the source?
>>>
>>
>>
On 21.06.19 13:30, Paolo Bonzini wrote:
> From: Liran Alon
>
> Previous commits have added support for migration of nested virtualization
> workloads. This was done by utilising two new KVM capabilities:
> KVM_CAP_NESTED_STATE and KVM_CAP_EXCEPTION_PAYLOAD. Both which are
> required in order
On 7/8/19 7:44 AM, Max Reitz wrote:
> On 05.07.19 18:45, John Snow wrote:
>>
>>
>> On 7/4/19 12:49 PM, Max Reitz wrote:
>>> On 03.07.19 23:55, John Snow wrote:
>
> [...]
>
+
+/**
+ * bdrv_dirty_bitmap_merge_internal: merge src into dest.
+ * Does NOT check bitmap
On 21.06.19 13:30, Paolo Bonzini wrote:
> From: Liran Alon
>
> Commit d98f26073beb ("target/i386: kvm: add VMX migration blocker")
> added a migration blocker for vCPU exposed with Intel VMX.
> However, migration should also be blocked for vCPU exposed with
> AMD SVM.
>
> Both cases should be
* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Fri, 5 Jul 2019 at 11:13, Paolo Bonzini wrote:
> >
> > On 05/07/19 11:58, Peter Maydell wrote:
> > > On Fri, 5 Jul 2019 at 10:48, Paolo Bonzini wrote:
> > >> You're right, the compatibility causes wrong behavior for the default
> > >> -rtc
Thanks Gerd,
Gentle ping on this.
Sam
> On 1 Jul 2019, at 10:41, Gerd Hoffmann wrote:
>
> On Wed, Jun 26, 2019 at 03:39:40PM +0300, Sam Eiderman wrote:
>> v1:
>>
>> Non-standard logical geometries break under QEMU.
>>
>> A virtual disk which contains an operating system which depends on
>>
On 7/6/19 12:03 AM, Markus Armbruster wrote:
> John Snow writes:
>
>> On 7/5/19 10:14 AM, Markus Armbruster wrote:
>>> John Snow writes:
>>>
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
On 08/07/2019 11:19, Daniel P. Berrangé wrote:
> On Mon, Jul 08, 2019 at 12:17:12PM +0200, Philippe Mathieu-Daudé wrote:
>> On 7/8/19 11:41 AM, Daniel P. Berrangé wrote:
>>> On Sat, Jul 06, 2019 at 09:35:30PM +0100, Peter Maydell wrote:
On Sat, 6 Jul 2019 at 11:28, Mark Cave-Ayland
This series might be helpful:
https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02067.html
** Tags added: linux-user
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1828723
Title:
[RFE]
latest series posted:
https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00191.html
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1797262
Title:
qemu arm no longer able to boot RPI Kernels
> On Jul 4, 2019, at 08:45, Philippe Mathieu-Daudé wrote:
>
> Cc'ing PPC/taihu_405ep and ARM/Digic4 maintainers.
>
> On 7/3/19 6:36 PM, Philippe Mathieu-Daudé wrote:
>> On 7/3/19 6:20 PM, Stephen Checkoway wrote:
On Jul 3, 2019, at 12:02, Philippe Mathieu-Daudé wrote:
On 7/3/19
Am 05.07.2019 um 17:28 hat Eric Blake geschrieben:
> Commit b76b4f60 allowed '-o compat=v3' as an alias for the
> less-appealing '-o compat=1.1' for 'qemu-img create' since we want to
> use the QMP form as much as possible, but forgot to do likewise for
> qemu-img amend. Also, it doesn't help
On Mon, 7 Jan 2019 at 12:23, Marc-André Lureau
wrote:
>
> Generalize machine compatibility properties
>
> During "[PATCH v2 05/10] qom/globals: generalize
> object_property_set_globals()" review, Eduardo suggested to rework the
>
Patchew URL:
https://patchew.org/QEMU/20190708144013.83474-1-borntrae...@de.ibm.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190708144013.83474-1-borntrae...@de.ibm.com
Type: series
Subject: [Qemu-devel] [PATCH] s390:
From: Philippe Mathieu-Daudé
The TPM Physical Presence Interface routines are only used
by the CRB/TIS interfaces. Do not compile this file if any
of them is built.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Marc-André Lureau
Reviewed-by: Stefan Berger
Signed-off-by: Stefan Berger
The following changes since commit 506179e42112be77bfd071f050b15762d3b2cd43:
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190702' into
staging (2019-07-02 18:56:44 +0100)
are available in the Git repository at:
git://github.com/stefanberger/qemu-tpm.git
1 - 100 of 203 matches
Mail list logo
