This adds a pathin= option to -chardev file, which allows specifying
distinct input and output paths for the chardev. This functionaliy was
already available through QMP.
Alexander Bulekov (2):
chardev: enable distinct input for -chardev file
char-file: add test for distinct path= and pathin=
On Thu, 7 May 2020 01:00:05 +0530
Kirti Wankhede wrote:
> On 5/6/2020 10:23 PM, Dr. David Alan Gilbert wrote:
> > * Cornelia Huck (coh...@redhat.com) wrote:
> >> On Wed, 6 May 2020 02:38:46 -0400
> >> Yan Zhao wrote:
> >>
> >>> On Tue, May 05, 2020 at 12:37:26PM +0800, Alex Williamson wrote:
Hi Stephen,
On 5/7/20 1:47 AM, Stephen Long wrote:
From: Ana Pazos
Signed-off-by: Ana Pazos
---
Submitting this patch on behalf of Ana Pazos. The bug was triggered by
the following c file on aarch64-linux-user.
This is fine, but you have to add your own S-o-b tag too.
See the link from
htt
char-file already supports distinct paths for input/output but it was
only possible to specify a distinct input through QMP. With this change,
we can also specify a distinct input with the -chardev file argument:
qemu -chardev file,id=char1,path=/out/file,pathin=/in/file
Signed-off-by: Alexand
Signed-off-by: Alexander Bulekov
---
tests/test-char.c | 83 +++
1 file changed, 83 insertions(+)
diff --git a/tests/test-char.c b/tests/test-char.c
index 3afc9b1b8d..9b3e1e2a9b 100644
--- a/tests/test-char.c
+++ b/tests/test-char.c
@@ -1228,6 +1228,88
Patchew URL:
https://patchew.org/QEMU/20200507050228.802395-1-da...@gibson.dropbear.id.au/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20200507050228.802395-1-da...@gibson.dropbear.id.au
Subject: [PULL 00/18] ppc-for-5.1 queue 2
On 5/7/2020 6:31 AM, Yan Zhao wrote:
On Tue, May 05, 2020 at 01:54:20AM +0800, Kirti Wankhede wrote:
This patch makes mtty device migration capable. Purpose od this code is
to test migration interface. Only stop-and-copy phase is implemented.
Postcopy migration is not supported.
Actual data
On 5/7/2020 1:33 AM, Alex Williamson wrote:
On Thu, 7 May 2020 01:18:19 +0530
Kirti Wankhede wrote:
On 5/6/2020 11:41 AM, Yan Zhao wrote:
On Tue, May 05, 2020 at 12:37:11PM +0800, Alex Williamson wrote:
On Tue, 5 May 2020 04:48:37 +0530
Kirti Wankhede wrote:
On 3/26/2020 1:26 AM, Ale
On 5/7/2020 3:57 AM, Alex Williamson wrote:
On Mon, 4 May 2020 21:28:58 +0530
Kirti Wankhede wrote:
Added migration capability in IOMMU info chain.
User application should check IOMMU info chain for migration capability
to use dirty page tracking feature provided by kernel module.
Signed-o
From: Greg Kurz
The CAS reboot flag is false by default and all the locations that
could set it to true have been dropped. This means that all code
blocks depending on the flag being set is dead code and the other
code blocks should be executed always.
Just do that and drop the now uneeded CAS r
From: Cédric Le Goater
The Radix tree translation model currently supports process-scoped
translation for the PowerNV machine (Hypervisor mode) and for the
pSeries machine (Guest mode). Guests running under an emulated
Hypervisor (PowerNV machine) require a new type of Radix translation,
called p
From: Daniele Buono
Starting with Clang v9, -Wtype-limits is implemented and triggers a
few "result of comparison is always true" errors when compiling PPC32
targets.
The comparisons seem to be necessary only on PPC64, since the
else branch in PPC32 only has a "g_assert_not_reached();" in all ca
From: Cédric Le Goater
This prepares ground for partition-scoped Radix translation.
Signed-off-by: Suraj Jitindar Singh
Signed-off-by: Cédric Le Goater
Reviewed-by: Greg Kurz
Message-Id: <20200403140056.59465-3-...@kaod.org>
Signed-off-by: David Gibson
---
target/ppc/mmu-radix64.c | 11
From: Cédric Le Goater
The ppc_radix64_walk_tree() routine walks through the nested radix
tables to look for a PTE.
Split it in two and introduce a new routine ppc_radix64_next_level()
which we will use for partition-scoped Radix translation when
translating the process tree addresses. The proto
From: Suraj Jitindar Singh
According to the ISA the root page directory size of a radix tree for
either process- or partition-scoped translation must be >= 5.
Thus add this to the list of conditions checked when validating the
partition table entry in validate_pate();
Signed-off-by: Suraj Jitin
The restrictions here (which are checked at pre-plug time) are PAPR
specific, rather than being inherent to the NVDIMM devices. Adjust the
error messages to be clearer about this.
Signed-off-by: David Gibson
---
hw/ppc/spapr_nvdimm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Cédric Le Goater
It will ease the introduction of new routines for partition-scoped
Radix translation.
Signed-off-by: Suraj Jitindar Singh
Signed-off-by: Cédric Le Goater
Message-Id: <20200330094946.24678-3-...@kaod.org>
Reviewed-by: Greg Kurz
Signed-off-by: David Gibson
---
target/pp
From: Daniel Henrique Barboza
The pseries machine does not support NVDIMM modules without label.
Attempting to do so, even if the overall block size is aligned with
256MB, will seg fault the guest kernel during NVDIMM probe. This
can be avoided by forcing 'label-size' to always be present for
sPA
From: Cédric Le Goater
Signed-off-by: Suraj Jitindar Singh
Signed-off-by: Cédric Le Goater
Message-Id: <20200330094946.24678-4-...@kaod.org>
Reviewed-by: Greg Kurz
Signed-off-by: David Gibson
---
target/ppc/mmu-radix64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/ppc/mmu-radi
Currently, we can't properly handle unplug of NVLink2 devices, because we
don't have code to tear down their special memory resources. There's not
a lot of impetus to implement that: since hardware NVLink2 devices can't
be hot unplugged, the guest side drivers don't usually support unplug
anyway.
From: Cédric Le Goater
This is moving code under a new ppc_radix64_xlate() routine shared by
the MMU Radix page fault handler and the 'get_phys_page_debug' PPC
callback. The difference being that 'get_phys_page_debug' does not
generate exceptions.
The specific part of process-scoped Radix transl
From: Nicholas Piggin
system calls (at least in Linux) use registers r3-r8 for inputs, so
include those registers in the dump.
This also adds a mode for PAPR hcalls, which have a different calling
convention.
Signed-off-by: Nicholas Piggin
Message-Id: <20200317054918.199161-1-npig...@gmail.com
From: Greg Kurz
The guest can select the MMU mode by setting bits 0-1 of byte 24
in OV5 to to 0b00 for hash or 0b01 for radix. As required by the
architecture, we terminate the boot process if any other value
is found there.
The usual way to negotiate features in OV5 is basically ANDing
the bitf
From: Greg Kurz
We currently check if some capability in OV5 was removed by the guest
since the previous CAS, and we trigger a CAS reboot in that case. This
was required because it could call for a device-tree property or node
removal, that we didn't support until recently (see commit 6787d27b04a
From: Nicholas Piggin
This implements the NMI interface for the PNV machine, similarly to
commit 3431648272d ("spapr: Add support for new NMI interface") for
SPAPR.
Signed-off-by: Nicholas Piggin
Message-Id: <20200325144147.221875-3-npig...@gmail.com>
Reviewed-by: Cédric Le Goater
Signed-off-b
From: Alexey Kardashevskiy
At the moment "ibm,client-architecture-support" ("CAS") is implemented
in SLOF and QEMU assists via the custom H_CAS hypercall which copies
an updated flatten device tree (FDT) blob to the SLOF memory which
it then uses to update its internal tree.
When we enable the O
The following changes since commit 570a9214827e3d42f7173c4d4c9f045b99834cf0:
Merge remote-tracking branch
'remotes/alistair/tags/pull-reg-to-apply-20200505' into staging (2020-05-06
15:38:02 +0100)
are available in the Git repository at:
git://github.com/dgibson/qemu.git tags/ppc-for-5.1-2
From: Nicholas Piggin
Rather than have the helper take an optional vector address
override, instead have its caller modify env->nip itself.
This is more consistent when adding pnv nmi support, and also
with mce injection added later.
Signed-off-by: Nicholas Piggin
Message-Id: <20200325144147.22
On Mon, May 04, 2020 at 16:43:52 +0200, Philippe Mathieu-Daudé wrote:
> When building with Clang 10 on Fedora 32, we get:
>
> tests/qht-bench.c:287:29: error: implicit conversion from 'unsigned long'
> to 'double' changes value from 18446744073709551615 to 18446744073709551616
> [-Werror,-Wimp
On 2020/5/7 4:25, Michael S. Tsirkin wrote:
> On Wed, May 06, 2020 at 07:42:19PM +0800, gengdongjiu wrote:
>> On 2020/4/17 21:32, Peter Maydell wrote:
>>> On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
In the ARMv8 platform, the CPU error types includes synchronous external
abor
** Merge proposal linked:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/383566
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rc
Thank you Maciej :)
Igor it seems like the IRQ being used is 5 and not 7 & 13 like in the
current patch. Seems like it needs to reside in the _CRS like you said.
Seems like it has all those _STA/_DIS/_PS0 just like the way it's
currently in the patch (unless I'm missing something).
Notice _
Patchew URL:
https://patchew.org/QEMU/alpine.deb.2.21.2005070038550.18...@digraph.polyomino.org.uk/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: alpine.deb.2.21.2005070038550.18...@digraph.polyomino.org.uk
Subject: [PATCH 0/5] ta
Patchew URL: https://patchew.org/QEMU/20200507005234.959590-1-and...@daynix.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
expor
On Tue, May 05, 2020 at 01:54:20AM +0800, Kirti Wankhede wrote:
> This patch makes mtty device migration capable. Purpose od this code is
> to test migration interface. Only stop-and-copy phase is implemented.
> Postcopy migration is not supported.
>
> Actual data for mtty device migration is very
The fscale implementation uses floatx80_scalbn for the final scaling
operation. floatx80_scalbn ends up rounding the result using the
dynamic rounding precision configured for the FPU. But only a limited
set of x87 floating-point instructions are supposed to respect the
dynamic rounding precision
The fscale implementation passes infinite exponents through to generic
code that rounds the exponent to a 32-bit integer before using
floatx80_scalbn. In round-to-nearest mode, and ignoring exceptions,
this works in many cases. But it fails to handle the special cases of
scaling 0 by a +Inf expon
The implementation of the fscale instruction returns a NaN exponent
unchanged. Fix it to return a quiet NaN when the provided exponent is
a signaling NaN.
Signed-off-by: Joseph Myers
---
target/i386/fpu_helper.c | 4
tests/tcg/i386/test-i386-fscale.c | 37
The fscale implementation does not check for invalid encodings in the
exponent operand, thus treating them like INT_MIN (the value returned
for invalid encodings by floatx80_to_int32_round_to_zero). Fix it to
treat them similarly to signaling NaN exponents, thus generating a
quiet NaN result.
Sig
The implementation of the fxtract instruction treats all nonzero
operands as normal numbers, so yielding incorrect results for invalid
formats, infinities, NaNs and subnormal and pseudo-denormal operands.
Implement appropriate handling of all those cases.
Signed-off-by: Joseph Myers
---
target/i
Among the various bugs in the x87 floating-point emulation that show
up through a combination of glibc testing and code inspection, there
are several in the implementations of the fxtract and fscale
instructions. This series fixes those bugs.
Bugs in other instructions, and bugs relating to float
From: Andrew Melnychenko
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1708065
Overall, there was an issue that big frames of IPv6 doesn't sent.
With network backend with 'virtual header' - there was an issue
in 'plen' field. Overall, during TSO, 'plen' would be changed,
but with 'vheader'
From: Ana Pazos
Signed-off-by: Ana Pazos
---
Submitting this patch on behalf of Ana Pazos. The bug was triggered by
the following c file on aarch64-linux-user.
> #include
> #include
>
> int main() {
> int PDeachSig = 0;
> if (prctl(PR_GET_PDEATHSIG, &PDeachSig) == 0 && PDeachSig == SIGKIL
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.6.10, v5.4.38, v4.19.120, v4.14.178,
v4.9.221, v4.4.221.
v5.6.10: Build OK!
v5.4
On Mon, 4 May 2020 21:28:58 +0530
Kirti Wankhede wrote:
> Added migration capability in IOMMU info chain.
> User application should check IOMMU info chain for migration capability
> to use dirty page tracking feature provided by kernel module.
>
> Signed-off-by: Kirti Wankhede
> ---
> drivers/
On Mon, 4 May 2020 21:28:57 +0530
Kirti Wankhede wrote:
> DMA mapped pages, including those pinned by mdev vendor drivers, might
> get unpinned and unmapped while migration is active and device is still
> running. For example, in pre-copy phase while guest driver could access
> those pages, host
As you correctly point out, this code needs to be looked at more
carefully so that
if the device does disconnect in the background we can handle the migration path
gracefully. In particular, we need to decide whether a migration
should be allowed
to continue if a device disconnects durning the migr
On 5/6/20 4:34 PM, Eyal Moscovici wrote:
The mapping operation of large disks especially ones stored over a
long chain of QCOW2 files can take a long time to finish.
Additionally when mapping fails there was no way recover by
restarting the mapping from the failed location.
The new options, --st
On 5/6/20 4:34 PM, Eyal Moscovici wrote:
The code handles this case correctly we merely skip the loop. However it
is probably best to return an explicit error.
Acked-by: Mark Kanda
Signed-off-by: Eyal Moscovici
---
qemu-img.c | 5 +
1 file changed, 5 insertions(+)
Reviewed-by: Eric Bl
On 5/6/20 4:34 PM, Eyal Moscovici wrote:
All calls to cvtnum check the return value and print the same error message more
or less. And so error reporting moved to cvtnum to reduce duplicate code and
provide a single error message.
Acked-by: Mark Kanda
Signed-off-by: Eyal Moscovici
---
qemu-i
** Merge proposal linked:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/383551
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rc
On 5/6/20 4:34 PM, Eyal Moscovici wrote:
Following commit f46bfdbfc8f95cf65d7818ef68a801e063c40332 (util/cutils: Change
qemu_strtosz*() from int64_t to uint64_t) which added a similar check to
cvtnum. As a result there is no need to check it separately outside of cvtnum.
Acked-by: Mark Kanda
Si
On 5/6/20 4:34 PM, Eyal Moscovici wrote:
Hi,
The following series adds two parameters to qemu-img map:
1. start-offset: mapping starting offset.
2. max-length: the length of the mapping.
These parameters proved useful when mapping large disk spread across
long store file chains. It allows us to
On 5/6/20 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
vhdx doesn't have .bdrv_co_block_status handler, so DATA|ALLOCATED is
always assumed for it. unallocated_blocks_are_zero is useless, drop it.
After the analysis I did in patch 1, this is correct. No behavior change.
Reviewed-by: Eric Bla
On 5/6/20 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
raw_co_block_status() in block/file-posix.c never returns 0, so
unallocated_blocks_are_zero is useless. Drop it.
As in 4/8, you are correct that it had no impact on block_status, but it
did affect qemu-img convert. So again, removing the
The mapping operation of large disks especially ones stored over a
long chain of QCOW2 files can take a long time to finish.
Additionally when mapping fails there was no way recover by
restarting the mapping from the failed location.
The new options, --start-offset and --max-length allows the user
Previously dump_map_entry identified whether we need to start a new JSON
array based on whether start address == 0. In this refactor we remove
this assumption as in following patches we will allow map to start from
an arbitrary position.
Reviewed-by: Eric Blake
Acked-by: Mark Kanda
Signed-off-by
The code handles this case correctly we merely skip the loop. However it
is probably best to return an explicit error.
Acked-by: Mark Kanda
Signed-off-by: Eyal Moscovici
---
qemu-img.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/qemu-img.c b/qemu-img.c
index 4a06ab7fe8..a1b507a0be
All calls to cvtnum check the return value and print the same error message more
or less. And so error reporting moved to cvtnum to reduce duplicate code and
provide a single error message.
Acked-by: Mark Kanda
Signed-off-by: Eyal Moscovici
---
qemu-img.c | 63 --
Hi,
The following series adds two parameters to qemu-img map:
1. start-offset: mapping starting offset.
2. max-length: the length of the mapping.
These parameters proved useful when mapping large disk spread across
long store file chains. It allows us to bound the execution time of each
qemu-img
Following commit f46bfdbfc8f95cf65d7818ef68a801e063c40332 (util/cutils: Change
qemu_strtosz*() from int64_t to uint64_t) which added a similar check to
cvtnum. As a result there is no need to check it separately outside of cvtnum.
Acked-by: Mark Kanda
Signed-off-by: Eyal Moscovici
---
qemu-img.
On 5/6/20 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
We set bdi->unallocated_blocks_are_zero = iscsilun->lbprz, but
iscsi_co_block_status doesn't return 0 in case of iscsilun->lbprz, it
returns ZERO when appropriate. So actually unallocated_blocks_are_zero
is useless. Drop it now.
Signed-off-b
On 5/6/20 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
It's false by default, no needs to set it. We are going to drop this
variable at all, so drop it now here, it doesn't hurt.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/crypto.c | 1 -
1 file changed, 1 deletion(-)
Trivially c
On 5/6/20 4:25 AM, Vladimir Sementsov-Ogievskiy wrote:
In case when get_image_offset() returns -1, we do zero out the
corresponding chunk of qiov. So, this should be reported as ZERO.
After block-status update, it never reports 0, so setting
unallocated_blocks_are_zero doesn't make sense. Drop i
On Tue, May 5, 2020 at 1:40 PM Alistair Francis wrote:
>
> On Fri, May 1, 2020 at 11:51 AM Jose Martins wrote:
> >
> > The spec states that on sv39x4 guest physical "address bits 63:41 must
> > all be zeros, or else a guest-page-fault exception occurs.". However,
> > the check performed for the
** Merge proposal linked:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/383545
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rc
On Tue, May 5, 2020 at 6:34 PM Bin Meng wrote:
>
> Hi Alistair,
>
> On Wed, May 6, 2020 at 6:37 AM Alistair Francis wrote:
> >
> > On Tue, May 5, 2020 at 1:34 PM Alistair Francis
> > wrote:
> > >
> > > On Fri, May 1, 2020 at 5:21 AM Bin Meng wrote:
> > > >
> > > > From: Bin Meng
> > > >
> > >
From: Andrew Melnychenko
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1707441
Added ICR clearing if there is IMS bit - according to the note by
section 13.3.27 of the 8257X developers manual.
Signed-off-by: Andrew Melnychenko
---
hw/net/e1000e_core.c | 9 +
hw/net/trace-events
On Wed, May 06, 2020 at 07:42:19PM +0800, gengdongjiu wrote:
> On 2020/4/17 21:32, Peter Maydell wrote:
> > On Fri, 10 Apr 2020 at 12:46, Dongjiu Geng wrote:
> >>
> >> In the ARMv8 platform, the CPU error types includes synchronous external
> >> abort(SEA)
> >> and SError Interrupt (SEI). If exce
On Fri, Apr 10, 2020 at 07:46:37PM +0800, Dongjiu Geng wrote:
> kvm_arch_on_sigbus_vcpu() error injection uses source_id as
> index in etc/hardware_errors to find out Error Status Data
> Block entry corresponding to error source. So supported source_id
> values should be assigned here and not be ch
On Fri, Apr 10, 2020 at 07:46:35PM +0800, Dongjiu Geng wrote:
> Record the GHEB address via fw_cfg file, when recording
> a error to CPER, it will use this address to find out
> Generic Error Data Entries and write the error.
>
> In order to avoid migration failure, make hardware
> error table add
On Fri, Apr 10, 2020 at 07:46:34PM +0800, Dongjiu Geng wrote:
> This patch builds Hardware Error Source Table(HEST) via fw_cfg blobs.
> Now it only supports ARMv8 SEA, a type of Generic Hardware Error
> Source version 2(GHESv2) error source. Afterwards, we can extend
> the supported types if needed
On Fri, Apr 10, 2020 at 07:46:33PM +0800, Dongjiu Geng wrote:
> This patch builds error_block_address and read_ack_register fields
> in hardware errors table , the error_block_address points to Generic
> Error Status Block(GESB) via bios_linker. The max size for one GESB
> is 1kb, For more detailed
FYIO, from now on all the "merge" work will be done in the merge
requests being linked to this BUG (at the top). @paelzer will be
verifying those.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
On Wed, 6 May 2020 at 00:18, Alistair Francis wrote:
>
> The following changes since commit f19d118bed77bb95681b07f4e76dbb700c16918d:
>
> Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2020-05-04' into
> staging (2020-05-05 15:47:44 +0100)
>
> are available in the Git repository at:
On Wed, May 6, 2020 at 1:20 PM Philippe Mathieu-Daudé
<1805...@bugs.launchpad.net> wrote:
>
> Isn't this fixed by commit 5710a3e09f9?
See comment #43. The discussions hence are about testing/integration
of that fix.
-dann
--
You received this bug notification because you are a member of qemu-
On Thu, 7 May 2020 01:18:19 +0530
Kirti Wankhede wrote:
> On 5/6/2020 11:41 AM, Yan Zhao wrote:
> > On Tue, May 05, 2020 at 12:37:11PM +0800, Alex Williamson wrote:
> >> On Tue, 5 May 2020 04:48:37 +0530
> >> Kirti Wankhede wrote:
> >>
> >>> On 3/26/2020 1:26 AM, Alex Williamson wrote:
> >
On 5/6/2020 11:41 AM, Yan Zhao wrote:
On Tue, May 05, 2020 at 12:37:11PM +0800, Alex Williamson wrote:
On Tue, 5 May 2020 04:48:37 +0530
Kirti Wankhede wrote:
On 3/26/2020 1:26 AM, Alex Williamson wrote:
On Wed, 25 Mar 2020 02:39:02 +0530
Kirti Wankhede wrote:
These functions save a
On 5/6/2020 1:45 PM, Yan Zhao wrote:
On Mon, May 04, 2020 at 11:58:56PM +0800, Kirti Wankhede wrote:
/*
* Helper Functions for host iova-pfn list
*/
@@ -567,6 +654,18 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
vfio_unpin_page_external(dma, i
On 5/6/2020 10:23 PM, Dr. David Alan Gilbert wrote:
* Cornelia Huck (coh...@redhat.com) wrote:
On Wed, 6 May 2020 02:38:46 -0400
Yan Zhao wrote:
On Tue, May 05, 2020 at 12:37:26PM +0800, Alex Williamson wrote:
It's been a long time, but that doesn't seem like what I was asking.
The sysfs
On 5/5/2020 11:46 AM, Philippe Mathieu-Daudé wrote:
Hi Kirti,
On 5/5/20 12:44 AM, Kirti Wankhede wrote:
This function will be used for migration region.
Migration region is mmaped when migration starts and will be unmapped
when
migration is complete.
Signed-off-by: Kirti Wankhede
Reviewe
Isn't this fixed by commit 5710a3e09f9?
commit 5710a3e09f9b85801e5ce70797a4a511e5fc9e2c
Author: Paolo Bonzini
Date: Tue Apr 7 10:07:46 2020 -0400
async: use explicit memory barriers
When using C11 atomics, non-seqcst reads and writes do not participate
in the total order of se
** Merge proposal linked:
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/383530
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rc
* Colin Walters (walt...@verbum.org) wrote:
> I'd like to make use of virtiofs as part of our tooling in
> https://github.com/coreos/coreos-assembler
> Most of the code runs as non-root today; qemu also runs as non-root.
> We use 9p right now.
>
> virtiofsd's builtin sandboxing effectively assumes
> Print the memory device info just like for other memory devices.
>
> Cc: "Dr. David Alan Gilbert"
> Cc: "Michael S. Tsirkin"
> Signed-off-by: David Hildenbrand
> ---
> monitor/hmp-cmds.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/monitor/hmp-cmds.c b/monitor/hm
> Let's add a proxy for virtio-mem, make it a memory device, and
> pass-through the properties.
>
> Cc: "Michael S. Tsirkin"
> Cc: Marcel Apfelbaum
> Cc: "Dr. David Alan Gilbert"
> Cc: Igor Mammedov
> Signed-off-by: David Hildenbrand
> ---
> hw/virtio/Makefile.objs| 1 +
> hw/virtio/vir
Sonora Pass is a 2 socket x86 motherboard designed by Facebook
and supported by OpenBMC. Strapping configuration was obtained
from hardware and i2c configuration is based on dts found at:
https://github.com/facebook/openbmc-linux/blob/1633c87b8ba7c162095787c988979b748ba65dc8/arch/arm/boot/dts/asp
Better handling of non-power-of-2 tails as seen with Arm 8-byte
vector operations.
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
---
tcg/tcg-op-gvec.c | 82 ---
1 file changed, 63 insertions(+), 19 deletions(-)
diff --git a/tcg/tcg-op-gve
For use when a target needs to pass a configure-specific
target_ulong value to duplicate.
Reviewed-by: LIU Zhiwei
Reviewed-by: David Hildenbrand
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
---
include/tcg/tcg-op-gvec.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/in
Add a version of tcg_gen_dup_* that takes both immediate and
a vector element size operand. This will replace the set of
tcg_gen_gvec_dup{8,16,32,64}i functions that encode the element
size within the function name.
Reviewed-by: LIU Zhiwei
Reviewed-by: David Hildenbrand
Reviewed-by: Alex Bennée
For the benefit of compatibility of function pointer types,
we have standardized on int32_t and int64_t as the integral
argument to tcg expanders.
We converted most of them in 474b2e8f0f7, but missed the rotates.
Reviewed-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Richar
We can now unify the implementation of the 3 VSPLTI instructions.
Acked-by: David Gibson
Signed-off-by: Richard Henderson
---
target/ppc/translate/vmx-impl.inc.c | 32 -
target/ppc/translate/vsx-impl.inc.c | 2 +-
2 files changed, 19 insertions(+), 15 deletions(-)
Replace the outgoing interface.
Reviewed-by: LIU Zhiwei
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
---
tcg/tcg-op-gvec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tcg/tcg-op-gvec.c b/tcg/tcg-op-gvec.c
index 593bb4542e..de16c027b3 100644
--- a/tc
We have this same parameter for GVecGen2i, GVecGen3,
and GVecGen3i. This will make some SVE2 insns easier
to parameterize.
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
---
include/tcg/tcg-op-gvec.h | 2 ++
tcg/tcg-op-gvec.c | 45 ---
2
tags/pull-tcg-20200506
for you to fetch changes up to 07dada0336a83002dfa8673a9220a88e13d9a45c:
tcg: Fix integral argument type to tcg_gen_rot[rl]i_i{32,64} (2020-05-06
09:25:10 -0700)
Add tcg_gen_gvec_dup_imm
Misc t
These interfaces are now unused.
Reviewed-by: LIU Zhiwei
Reviewed-by: David Hildenbrand
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
---
include/tcg/tcg-op-gvec.h | 5 -
tcg/tcg-op-gvec.c | 28
2 files changed, 33 deletions(-)
diff --git
In a few cases, we're able to remove some manual replication.
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
---
target/arm/translate-a64.c | 10 +-
target/arm/translate-sve.c | 12 +---
target/arm/translate.c | 9 ++---
3 files changed, 16 insertions(+), 15
The gen_gvec_dupi switch is unnecessary with the new function.
Replace it with a local gen_gvec_dup_imm that takes care of the
register to offset conversion and length arguments.
Drop zero_vec and use use gen_gvec_dup_imm with 0.
Reviewed-by: David Hildenbrand
Reviewed-by: Alex Bennée
Signed-of
On Wed, May 06, 2020 at 06:06:34PM +, Amithash Prasad wrote:
> >> + mc->desc = "OpenPOWER SonoraPass BMC (ARM1176)";
> Open Compute Project?
Oops. Yeah, this is not an OpenPOWER machine. Will send a v3.
--
Patrick Williams
signature.asc
Description: PGP signature
On 5/5/20 12:38 PM, Alberto Garcia wrote:
Extended L2 entries are bigger than normal L2 entries so this has an
impact on the amount of metadata needed for a qcow2 file.
Signed-off-by: Alberto Garcia
Reviewed-by: Max Reitz
---
block/qcow2.c | 19 ---
1 file changed, 12 insert
1 - 100 of 286 matches
Mail list logo
