For the pseries-2.12 machine type, make the spapr-caps SPAPR_CAP_CFPC
and SPAPR_CAP_SBBC default to workaround. Thus if the host is capable
the guest will be able to take advantage of these workarounds by default.
Otherwise if the host doesn't have these capabilities qemu will fail to
start and the
Change the macro that generates the vmstate migration field and the needed
function for the spapr-caps to take the full spapr-cap name. This has
the benefit of meaning this instance will be picked up when greping
for the spapr-caps and making it more obvious what this macro is doing.
Signed-off-by
The spapr-cap cap-ibs can only have values broken or fixed as there is
no workaround. Currently setting the value workaround will hit an assert
if the guest makes the hcall h_get_cpu_characteristics.
Thus this capability is better suited to being represented as a boolean.
Setting this to OFF corre
Move necessary stuff in escc.h and update type names.
Remove slavio_serial_ms_kbd_init().
Fix code style problems reported by checkpatch.pl
Update mac_newworld, mac_oldworld and sun4m to use directly the
QDEV interface.
Signed-off-by: Laurent Vivier
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-b
The patch 23bdb6f7ce73c33f96449e43b4cae01e55f79ae1 appears to be
segfaulting `qemu-img` at `replay_mutex_lock`.
The problem does not happen on the patch base
bc2943d6caf787e1c9a5f3109cdb98f37630b89e
The command is:
buildroot/output.x86_64~/images
../host/bin/qemu-img convert -f raw -O qc
On Tue, Feb 13, 2018 at 11:44:09PM -0500, Jintack Lim wrote:
> Hi,
>
> I'm trying to assign network devices to nested VMs on x86 using KVM,
> but I got network device driver errors in the nested VMs. (I've tried
> this about an year ago when vIOMMU patches were not upstreamed, and I
> got similar
On Tue, Feb 13, 2018 at 10:57:46PM +, Mark Cave-Ayland wrote:
> On 13/02/18 13:01, Laurent Vivier wrote:
>
> > Hi,
> >
> > can a maintainer of one of the involved parts take this in his
> > maintenance branch to have this merged?
> >
> > Thanks,
> > Laurent
> >
> > On 29/01/2018 15:21, Laur
On Tue, Feb 13, 2018 at 08:11:00PM +, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > It pauses an ongoing migration. Currently it only supports postcopy.
> > Note that this command will work on either side of the migration.
> > Basically when we trigger this on one s
On Tue, Feb 13, 2018 at 07:45:09PM +, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > Sister command to migrate-recover in QMP.
> >
> > Signed-off-by: Peter Xu
>
> Yes, useful for testing, although we don't have any OOB equivalent yet,
> something I need to look at.
Hi,
I'm trying to assign network devices to nested VMs on x86 using KVM,
but I got network device driver errors in the nested VMs. (I've tried
this about an year ago when vIOMMU patches were not upstreamed, and I
got similar errors at that time.)
This could be network driver issues, but I'd like
On 2/13/2018 at 5:11 PM, Michael Roth wrote:
> This blog entry is intended as a follow‑up to the original entry in
> January regarding Spectre/Meltdown and the proposed changes to address
> them in the upcoming 2.11.1 release.
>
> This entry is meant to accompany the 2.11.1 release (planned for
>
On Tue, Feb 13, 2018 at 06:56:51PM +, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > The first allow-oob=true command. It's used on destination side when
> > the postcopy migration is paused and ready for a recovery. After
> > execution, a new migration channel will
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/916720
Title:
select fails
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/855630
Title:
Cant Run Win
On Tue, Feb 13, 2018 at 06:17:51PM +, Dr. David Alan Gilbert wrote:
> * Peter Xu (pet...@redhat.com) wrote:
> > After we updated the dirty bitmaps of ramblocks, we also need to update
> > the critical fields in RAMState to make sure it is ready for a resume.
> >
> > Signed-off-by: Peter Xu
>
For the pseries-2.12 machine type, make the spapr-caps SPAPR_CAP_CFPC
and SPAPR_CAP_SBBC default to workaround. This means the guest will
be able to take advantage of these workarounds by default, so long
as the host is capable.
Signed-off-by: Suraj Jitindar Singh
---
hw/ppc/spapr.c | 11 ++
The spapr-cap cap-ibs can only have values broken or fixed as there is
no workaround. Currently setting the value workaround will hit an assert
if the guest makes the hcall h_get_cpu_characteristics.
Report an error when attempting to apply the setting with a more helpful
error message.
Reported-
Change the macro that generates the vmstate migration field and the needed
function for the spapr-caps to take the full spapr-cap name. This has
the benefit of meaning this instance will be picked up when greping
for the spapr-caps and making it more obvious what this macro is doing.
Signed-off-by
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Wednesday, February 14, 2018 12:44 AM
> To: Zhoujian (jay)
> Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Huangweidong (C)
> ; stefa...@redhat.com; pa...@linux.vnet.ibm.com;
> longpeng ; xin.z...@intel.com;
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Wednesday, February 14, 2018 12:47 AM
> To: Zhoujian (jay)
> Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Huangweidong (C)
> ; stefa...@redhat.com; pa...@linux.vnet.ibm.com;
> longpeng ; xin.z...@intel.com;
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Wednesday, February 14, 2018 12:46 AM
> To: Zhoujian (jay)
> Cc: qemu-devel@nongnu.org; pbonz...@redhat.com; Huangweidong (C)
> ; stefa...@redhat.com; pa...@linux.vnet.ibm.com;
> longpeng ; xin.z...@intel.com;
> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-
> bounces+jianjay.zhou=huawei@nongnu.org] On Behalf Of Michael S. Tsirkin
> Sent: Wednesday, February 14, 2018 12:52 AM
> To: Peter Maydell
> Cc: QEMU Developers
> Subject: Re: [Qemu-devel] [PULL 00/26] virtio, vhost, pci, pc
On Tue, Feb 13, 2018 at 07:20:56PM +1100, Alexey Kardashevskiy wrote:
> On 13/02/18 16:41, David Gibson wrote:
> > On Tue, Feb 13, 2018 at 04:36:30PM +1100, David Gibson wrote:
> >> On Tue, Feb 13, 2018 at 12:15:52PM +1100, Alexey Kardashevskiy wrote:
> >>> On 13/02/18 03:06, Alex Williamson wrote:
Ping?
On Thu, Jan 4, 2018 at 6:18 AM, Eric Blake wrote:
> On 12/24/2017 08:51 PM, Fam Zheng wrote:
>> Signed-off-by: Fam Zheng
>>
>> ---
>>
>> v2: Actually test the thing. [Kevin]
>> ---
>> tests/qemu-iotests/153 | 8 +---
>> tests/qemu-iotests/153.out | 7 ---
>> 2 files changed, 9
On Tue, 02/13 18:09, Daniel P. Berrangé wrote:
> On Tue, Feb 13, 2018 at 05:34:25PM +, Stefan Hajnoczi wrote:
> > From: Fam Zheng
> >
> > git-publish [1] is a convenient tool to send patches and has been
> > popular among QEMU developers. Recently it has been made available in
> > Fedora off
On Tue, 02/13 17:34, Stefan Hajnoczi wrote:
> The following changes since commit fb68096da3d35e64c88cd610c1fa42766c58e92a:
>
> Revert "tests: use memfd in vhost-user-test" (2018-02-13 09:51:52 +)
>
> are available in the Git repository at:
>
> git://github.com/stefanha/qemu.git tags/bloc
This blog entry is intended as a follow-up to the original entry in
January regarding Spectre/Meltdown and the proposed changes to address
them in the upcoming 2.11.1 release.
This entry is meant to accompany the 2.11.1 release (planned for
2018-02-14) and document how to make use of the new optio
On Tue, Feb 13, 2018 at 14:10:20 -0800, Richard Henderson wrote:
> On 02/13/2018 01:55 PM, Emilio G. Cota wrote:
> > Are we planning to use BS_STOP in the future? I see it has no setters,
> > although we check for it in gen_intermediate_code:
>
> No, but the whole port should be converted to exec/
On Tue, Feb 13, 2018 at 03:37:16PM -0200, Daniel Henrique Barboza wrote:
1;5002;0c> Newer kernels have a htab resize capability when adding or remove
> memory. At these situations, the guest kernel might reallocate its
> htab to a more suitable size based on the resulting memory.
>
> However, we'r
We want to limit the use of the term 'size' for only values that
count by bytes. Renaming fields in the spec does not invalidate
any existing implementation, but may make future implementations
easier to write.
A reasonable followup would be to rename internal qemu code that
operates on qcow2 ima
I mentioned this while reviewing Berto's series on L2 slice handling;
this is a first cut at patches that I think are worth doing throughout
the qcow2 code base if we like the idea.
Eric Blake (2):
qcow2: Prefer 'entries' over 'size' for non-byte values in spec
qcow2: Prefer 'entries' over 'si
Using 'size' for anything other than bytes is difficult to
reason about; let's rename entries related to the number of
entries in a cache accordingly.
Signed-off-by: Eric Blake
---
block/qcow2.h | 4 ++--
block/qcow2.c | 21 +++--
2 files changed, 13 insertions(+), 12 deletions(
On 13/02/18 13:01, Laurent Vivier wrote:
Hi,
can a maintainer of one of the involved parts take this in his
maintenance branch to have this merged?
Thanks,
Laurent
On 29/01/2018 15:21, Laurent Vivier wrote:
Paolo,
I forgot to cc: you for the "MAINTAINERS/Character devices/Odd Fixes".
Could
On Tue, Feb 13, 2018 at 2:15 PM, Michael S. Tsirkin wrote:
> On Tue, Feb 13, 2018 at 12:24:40PM -0800, Andrey Smirnov wrote:
>> On Tue, Feb 13, 2018 at 10:13 AM, Michael S. Tsirkin wrote:
>> > On Tue, Feb 13, 2018 at 09:07:10AM -0800, Andrey Smirnov wrote:
>> >> +static void designware_pcie_root_
On Tue, Feb 13, 2018 at 09:53:58PM +0100, Peter Lieven wrote:
>
> Am 21.12.2017 um 15:29 schrieb Michael S. Tsirkin:
> > Backends don't need to know what frontend requested a reset,
> > and notifying then from virtio_error is messy because
> > virtio_error itself might be invoked from backend.
> >
On Tue, Feb 13, 2018 at 12:24:40PM -0800, Andrey Smirnov wrote:
> On Tue, Feb 13, 2018 at 10:13 AM, Michael S. Tsirkin wrote:
> > On Tue, Feb 13, 2018 at 09:07:10AM -0800, Andrey Smirnov wrote:
> >> +static void designware_pcie_root_class_init(ObjectClass *klass, void
> >> *data)
> >> +{
> >> +
On 02/13/2018 01:55 PM, Emilio G. Cota wrote:
> On Thu, Feb 08, 2018 at 14:28:34 +1300, Michael Clark wrote:
>> TCG code generation for the RV32IMAFDC and RV64IMAFDC. The QEMU
>> RISC-V code generator has complete coverage for the Base ISA v2.2,
>> Privileged ISA v1.9.1 and Privileged ISA v1.10:
>>
On Tue, Feb 13, 2018 at 12:29:39PM -0800, Jonathan Helman wrote:
>
>
> On 02/05/2018 04:08 AM, Tomáš Golembiovský wrote:
> > ping
> >
> > On Tue, 5 Dec 2017 13:14:46 +0100
> > Tomáš Golembiovský wrote:
> >
>
> It would be good to include the corresponding upstream kernel change in the
> comm
On Thu, Feb 08, 2018 at 14:28:34 +1300, Michael Clark wrote:
> TCG code generation for the RV32IMAFDC and RV64IMAFDC. The QEMU
> RISC-V code generator has complete coverage for the Base ISA v2.2,
> Privileged ISA v1.9.1 and Privileged ISA v1.10:
>
> - RISC-V Instruction Set Manual Volume I: User-L
On Thu, Feb 08, 2018 at 14:28:34 +1300, Michael Clark wrote:
> TCG code generation for the RV32IMAFDC and RV64IMAFDC. The QEMU
> RISC-V code generator has complete coverage for the Base ISA v2.2,
> Privileged ISA v1.9.1 and Privileged ISA v1.10:
>
> - RISC-V Instruction Set Manual Volume I: User-L
On 02/13/2018 04:04 PM, Laszlo Ersek wrote:
On 02/13/18 21:29, Stefan Berger wrote:
On 02/13/2018 02:59 PM, Laszlo Ersek wrote:
On 02/13/18 20:37, Kevin O'Connor wrote:
On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
On 02/12/18 21:49, Stefan Berger wrote:
On 02/12/2018 03:46 P
On 02/13/18 21:29, Stefan Berger wrote:
> On 02/13/2018 02:59 PM, Laszlo Ersek wrote:
>> On 02/13/18 20:37, Kevin O'Connor wrote:
>>> On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
On 02/12/18 21:49, Stefan Berger wrote:
> On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
>>
Consider the following code:
0x100 cmp %g5, 3
0x104 be 0x200
0x108 b 0x300
I believe this is what is described on page 55 of the sparc v8 manual as
unpredictable behavior, where a Bicc precedes an unconditional branch.
QEMU actually crashes unless run in GDB. Single stepping will a
Consider pc==0x100:
0x100 b 0x104
The uncondtional not-annulled branch will go to 0x104, which is the next
instruction anyway. do_branch() will leave dc->pc and dc->npc both set to
0x104. This causes gdb to have a problem when single stepping. It will be
stuck. QEMU will execute past this so
I/O currently being synchronous, there is no reason to ever clear the
SR_TXE bit. However the SR_TC bit may be cleared by software writing
to the SR register, so set it on each write.
In addition, fix the reset value of the USART status register.
Signed-off-by: Richard Braun
---
hw/char/stm32f2
Am 21.12.2017 um 15:29 schrieb Michael S. Tsirkin:
> Backends don't need to know what frontend requested a reset,
> and notifying then from virtio_error is messy because
> virtio_error itself might be invoked from backend.
>
> Let's just set the status directly.
>
> Cc: qemu-sta...@nongnu.org
> Re
On 02/13/2018 02:08 AM, linzhecheng wrote:
> g_free() was moved from vhost_net_cleanup in commit e6bcb1b, so we should
> free net after vhost_net_cleanup
>
> Signed-off-by: linzhecheng
Reviewed-by: Philippe Mathieu-Daudé
>
> diff --git a/net/vhost-user.c b/net/vhost-user.c
> index cb45512506.
On Tue, 13 Feb 2018 17:18:46 +0100
Gerd Hoffmann wrote:
> Wire up region-based display.
>
> Signed-off-by: Gerd Hoffmann
> ---
> hw/vfio/pci.h | 1 +
> include/hw/vfio/vfio-common.h | 8
> hw/vfio/display.c | 102
> +
On 02/05/2018 04:08 AM, Tomáš Golembiovský wrote:
ping
On Tue, 5 Dec 2017 13:14:46 +0100
Tomáš Golembiovský wrote:
It would be good to include the corresponding upstream kernel change in
the commit message. This would be similar to a previous change:
https://lists.gnu.org/archive/html/q
On 02/13/2018 02:59 PM, Laszlo Ersek wrote:
On 02/13/18 20:37, Kevin O'Connor wrote:
On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
On 02/12/18 21:49, Stefan Berger wrote:
On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
I'm not sure I fully understand the goals of the PPI interfa
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the vmdk driver accordingly. Drop the
now-unused vmdk_find_index_in_cluster().
Also, fix a pre-existing bug: if find_extent() fails (unlikely,
since the block layer did a bounds check), then we must return a
fa
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the vvfat driver accordingly. Note that we
can rely on the block driver having already clamped limits to our
block size, and simplify accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogie
We are gradually moving away from sector-based interfaces, towards
byte-based. Now that all drivers have been updated to provide the
byte-based .bdrv_co_block_status(), we can delete the sector-based
interface.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam
There are patches floating around to add NBD_CMD_BLOCK_STATUS,
but NBD wants to report status on byte granularity (even if the
reporting will probably be naturally aligned to sectors or even
much higher levels). I've therefore started the task of
converting our block status code to report at a byt
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the sheepdog driver accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam Zheng
Reviewed-by: Jeff Cody
---
v7: rebase to minor spacing changes in master
v5-v6: no
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the vpc driver accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam Zheng
---
v7: tweak commit message and type of 'n' [Fam]
v6: no change
v5: fix incorrect round
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the qed driver accordingly, taking the opportunity
to inline qed_is_allocated_cb() into its lone caller (the callback
used to be important, until we switched qed to coroutines). There is
no intent to optimize ba
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert all uses of
the allocmap (no semantic change). Callers that already had bytes
available are simpler, and callers that now scale to bytes will be
easier to switch to byte-based in th
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the qcow2 driver accordingly.
For now, we are ignoring the 'want_zero' hint. However, it should
be relatively straightforward to honor the hint as a way to return
larger *pnum values when we have consecutive cl
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the vdi driver accordingly. Note that the
TODO is already covered (the block layer guarantees bounds of its
requests), and that we can remove the now-unused s->block_sectors.
Signed-off-by: Eric Blake
Reviewed
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the null driver accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam Zheng
---
v6-v7: no change
v5: minor fix to type of 'ret'
v4: rebase to interface tweak
v3: n
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the generic helpers, and all passthrough clients
(blkdebug, commit, mirror, throttle) accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam Zheng
---
v6-v7: no cha
Rework the debug define so that we always get -Wformat checking,
even when debugging is disabled.
Signed-off-by: Eric Blake
Reviewed-by: Stefan Weil
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam Zheng
---
v2-v7: no change
---
block/vdi.c | 12
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the gluster driver accordingly.
In want_zero mode, we continue to report fine-grained hole
information (the caller wants as much mapping detail as possible);
but when not in that mode, the caller prefers larger
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the iscsi driver accordingly. In this case,
it is handy to teach iscsi_co_block_status() to handle a NULL map
and file parameter, even though the block layer passes non-NULL
values, because we also call the func
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the file protocol driver accordingly.
In want_zero mode, we continue to report fine-grained hole
information (the caller wants as much mapping detail as possible);
but when not in that mode, the caller prefers l
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the qcow driver accordingly. There is no
intent to optimize based on the want_zero flag for this format.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam Zheng
---
v5-v7:
We are gradually moving away from sector-based interfaces, towards
byte-based. Now that the block layer exposes byte-based allocation,
it's time to tackle the drivers. Add a new callback that operates
on as small as byte boundaries. Subsequent patches will then update
individual drivers, then fina
We are gradually converting to byte-based interfaces, as they are
easier to reason about than sector-based. Convert all uses of
the cluster size in sectors, along with adding assertions that we
are not dividing by zero.
Improve some comment grammar while in the area.
Signed-off-by: Eric Blake
A
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the parallels driver accordingly. Note that
the internal function block_status() is still sector-based, because
it is still in use by other sector-based functions; but that's okay
because request_alignment is 51
Commit bdd6a90 has a bug: drivers should never directly set
BDRV_BLOCK_ALLOCATED, but only io.c should do that (as needed).
Instead, drivers should report BDRV_BLOCK_DATA if it knows that
data comes from this BDS.
But let's look at the bigger picture: semantically, the nvme
driver is similar to th
We are gradually moving away from sector-based interfaces, towards
byte-based. Update the raw driver accordingly.
Signed-off-by: Eric Blake
Reviewed-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Fam Zheng
---
v5-v7: no change
v4: rebase to interface tweak
v3: no change
v2: rebase to mapping
-
On Tue, Feb 13, 2018 at 10:13 AM, Michael S. Tsirkin wrote:
> On Tue, Feb 13, 2018 at 09:07:10AM -0800, Andrey Smirnov wrote:
>> +static void designware_pcie_root_class_init(ObjectClass *klass, void *data)
>> +{
>> +PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>> +DeviceClass *dc = DEVICE_
* Peter Xu (pet...@redhat.com) wrote:
> Wrapper for QMP command "migrate-pause".
>
> Signed-off-by: Peter Xu
Reviewed-by: Dr. David Alan Gilbert
> ---
> hmp-commands.hx | 14 ++
> hmp.c | 9 +
> hmp.h | 1 +
> 3 files changed, 24 insertions(+)
>
> di
* Peter Xu (pet...@redhat.com) wrote:
> It pauses an ongoing migration. Currently it only supports postcopy.
> Note that this command will work on either side of the migration.
> Basically when we trigger this on one side, it'll interrupt the other
> side as well since the other side will get noti
On 02/13/18 20:37, Kevin O'Connor wrote:
> On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
>> On 02/12/18 21:49, Stefan Berger wrote:
>>> On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
I'm not sure I fully understand the goals of the PPI interface.
Here's what I understand so
On 13 February 2018 at 15:51, Paolo Bonzini wrote:
> The following changes since commit 7d848450b6e2a3e14a776b4c93704710e7f3d233:
>
> Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.12-20180212'
> into staging (2018-02-12 14:52:48 +)
>
> are available in the git repository at:
On 02/13/2018 07:46 PM, Eric Blake wrote:
> On 02/13/2018 08:48 AM, Daniel P. Berrangé wrote:
No, that's policy decision that doesn't matter from QMP pov. If the
mgmt
app wants the snapshot to be wrt to the initial time, it can simply
invoke the "stop" QMP command before doing t
* Peter Xu (pet...@redhat.com) wrote:
> Sister command to migrate-recover in QMP.
>
> Signed-off-by: Peter Xu
Yes, useful for testing, although we don't have any OOB equivalent yet,
something I need to look at.
Reviewed-by: Dr. David Alan Gilbert
> ---
> hmp-commands.hx | 13 +
>
On 13 February 2018 at 16:41, Geert Uytterhoeven
wrote:
> It is not uncommon for a contemporary FDT to be larger than 64 KiB,
> leading to failures loading the device tree from sysfs:
>
> qemu-system-aarch64: qemu_fdt_setprop: Couldn't set ...: FDT_ERR_NOSPACE
>
> For reference, the largest ar
Gerd Hoffmann writes:
>> +/*
>> + * ObjectInfo dataset received from initiator
>> + * Fields we don't care about are ignored
>> + */
>> +typedef struct {
>> +char __pad1[4];
>
> So, is this really padding or a field we don't care about?
>
> If the latter I'd suggest to give them proper names
On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
> On 02/12/18 21:49, Stefan Berger wrote:
> > On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
> >> I'm not sure I fully understand the goals of the PPI interface.
> >> Here's what I understand so far:
> >>
> >> The TPM specs define some ac
Gerd Hoffmann writes:
>> +#ifndef CONFIG_INOTIFY1
>> +/* Assumes that children, if any, have been already freed */
>> +static void usb_mtp_object_free_one(MTPState *s, MTPObject *o)
>> +{
>> +assert(o->nchildren == 0);
>> +QTAILQ_REMOVE(&s->objects, o, next);
>> +g_free(o->name);
>> +
On 02/13/18 17:28, Daniel P. Berrangé wrote:
> On Fri, Feb 09, 2018 at 07:12:59PM +, Shaun Reitan wrote:
>> QEMU leaves the pidfile behind on a clean exit when using the option
>> -pidfile /var/run/qemu.pid.
>>
>> Should QEMU leave it behind or should it clean up after itself?
>>
>> I'm willing
On 01/16/2018 12:08 AM, Fam Zheng wrote:
This is a new protocol driver that exclusively opens a host NVMe
controller through VFIO. It achieves better latency than linux-aio by
completely bypassing host kernel vfs/block layer.
$rw-$bs-$iodepth linux-aio nvme://
On 9 February 2018 at 08:57, Philippe Mathieu-Daudé wrote:
> Since v1:
> - corrected buggy UART base address (noticed by Peter)
> - tested using openbmc-build provided by Andrew
> - added Cédric R-b
>
> tested with:
>
> $ qemu-system-arm -M romulus-bmc -m 512 \
> -drive file=image-bmc,if=mtd
On 13 February 2018 at 17:16, Abdallah Bouassida
wrote:
> This patch offers to GDB the ability to read/write all the coprocessor
> registers for ARM and ARM64 by generating dynamically an XML-description for
> these registers.
>
> Signed-off-by: Abdallah Bouassida
> ---
> Hi Peter,
>
> http://pat
On 02/13/2018 12:49 PM, Max Reitz wrote:
On 2018-01-18 17:44, Pino Toscano wrote:
Rewrite the implementation of the ssh block driver to use libssh instead
of libssh2. The libssh library has various advantages over libssh2:
- easier API for authentication (for example for using ssh-agent)
- easi
* Peter Xu (pet...@redhat.com) wrote:
> The first allow-oob=true command. It's used on destination side when
> the postcopy migration is paused and ready for a recovery. After
> execution, a new migration channel will be established for postcopy to
> continue.
>
> Signed-off-by: Peter Xu
> ---
On 2018-01-18 17:44, Pino Toscano wrote:
> Rewrite the implementation of the ssh block driver to use libssh instead
> of libssh2. The libssh library has various advantages over libssh2:
> - easier API for authentication (for example for using ssh-agent)
> - easier API for known_hosts handling
> -
On 02/13/2018 11:36 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi Eric!
I'm now testing my nbd block status realization (block_status part, not
about dirty bitmaps), and faced into the following effect.
I created empty qcow2 image and wrote to the first sector, so
qemu-io -c map x
reports:
64
On 13 February 2018 at 15:19, Eric Blake wrote:
> On 02/13/2018 08:00 AM, Peter Maydell wrote:
>> +++ b/scripts/tracetool/backend/log.py
>> @@ -20,7 +20,7 @@ PUBLIC = True
>> def generate_h_begin(events, group):
>> -out('#include "qemu/log.h"',
>> +out('#include "qemu/log-for-trace.h
* Peter Xu (pet...@redhat.com) wrote:
> After we updated the dirty bitmaps of ramblocks, we also need to update
> the critical fields in RAMState to make sure it is ready for a resume.
>
> Signed-off-by: Peter Xu
> ---
> migration/ram.c| 40 +++-
> mig
On 13 February 2018 at 16:52, Michael S. Tsirkin wrote:
> I've dropped the crypto vhost patches from the pull request for now.
>
> Pushed with the same name - should be fine now.
Applied the fixed version, thanks.
-- PMM
On 02/13/2018 06:00 AM, Peter Maydell wrote:
> A persistent build problem we see is where a source file
> accidentally omits the #include of log.h. This slips through
> local developer testing because if you configure with the
> default (log) trace backend trace.h will pull in log.h for you.
> Comp
On Tue, Feb 13, 2018 at 09:07:10AM -0800, Andrey Smirnov wrote:
> +static void designware_pcie_root_class_init(ObjectClass *klass, void *data)
> +{
> +PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +
> +set_bit(DEVICE_CATEGORY_BRIDGE, dc->catego
On Tue, Feb 13, 2018 at 05:34:25PM +, Stefan Hajnoczi wrote:
> From: Fam Zheng
>
> git-publish [1] is a convenient tool to send patches and has been
> popular among QEMU developers. Recently it has been made available in
> Fedora official repo thanks to Stefan's work.
>
> One nice feature o
On 02/13/2018 02:05 AM, Peter Maydell wrote:
> Trivial-but-important nit: all these new files are missing
> copyright-and-license comment headers.
Oops, fixed. I also added a one-line comment describing what each of the tests
are attempting.
r~
On Tue, 13 Feb 2018 17:12:40 +0100
David Hildenbrand wrote:
> Currently, all memory accesses go via the MMU of the address space
> (primary, secondary, ...). This is bad, because we don't flush the TLB
> when disabling/enabling DAT. So we could add a tlb flush. However it
> is easier to simply se
On Tue, 13 Feb 2018 08:31:21 -0800 (PST)
no-re...@patchew.org wrote:
> Checking PATCH 1/1: s390x/tcg: fix disabling/enabling DAT...
> WARNING: line over 80 characters
> #32: FILE: target/s390x/cpu.h:320:
> +#define FLAG_MASK_PSW(FLAG_MASK_PER | FLAG_MASK_DAT |
> FLAG_MASK_PSTATE \
1 - 100 of 413 matches
Mail list logo
