We have a function that takes an additional condition parameter
over the standard backend interface. It already takes care of
eliding no-op moves.
Signed-off-by: Richard Henderson
---
tcg/arm/tcg-target.inc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This patch merely changes the interface, aborting on all failures,
of which there are currently none.
Reviewed-by: Alex Bennée
Reviewed-by: David Hildenbrand
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: David Gibson
Signed-off-by: Richard Henderson
---
tcg/aarch64/tcg-target.inc.c | 5
The gvec expanders perform a modulo on the shift count. If the target
requires alternate behaviour, then it cannot use the generic gvec
expanders anyway, and will have to have its own custom code.
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
---
accel/tcg/tcg-runtime.h | 15
The i386 backend already has these functions, and the aarch64 backend
could easily split out one. Nothing is done with these functions yet,
but this will aid register allocation of INDEX_op_dup_vec in a later patch.
Adjust the aarch64 tcg_out_dupi_vec signature to match the new interface.
The only fixed_reg is cpu_env, and it should not be modified
during any TB. Therefore code that tries to special-case moves
into a fixed_reg is dead. Remove it.
Reviewed-by: Alex Bennée
Reviewed-by: David Hildenbrand
Signed-off-by: Richard Henderson
---
tcg/tcg.c | 87
Allow the backend to expand dup from memory directly, instead of
forcing the value into a temp first. This is especially important
if integer/vector register moves do not exist.
Note that officially tcg_out_dupm_vec is allowed to fail.
If it did, we could fix this up relatively easily:
VECE
Use tcg_can_emit_vec_op instead of just TCG_TARGET_HAS_neg_vec,
so that we check the type and vece for the actual operation.
Reviewed-by: Alex Bennée
Signed-off-by: Richard Henderson
---
tcg/optimize.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tcg/optimize.c
PowerPC Altivec does not support direct moves between vector registers
and general registers. So when tcg_out_mov fails, we can use the
backing memory for the temporary to perform the move.
Acked-by: David Hildenbrand
Signed-off-by: Richard Henderson
---
tcg/tcg.c | 31
This case is similar to INDEX_op_mov_* in that we need to do
different things depending on the current location of the source.
Signed-off-by: Richard Henderson
---
v3: Added some commentary to the tcg_reg_alloc_* functions.
---
tcg/aarch64/tcg-target.inc.c | 9 ++-
tcg/i386/tcg-target.inc.c
From: David Hildenbrand
Let's add tcg_gen_gvec_3i(), similar to tcg_gen_gvec_2i(), however
without introducing "gen_helper_gvec_3i *fnoi", as it isn't needed
for now.
Reviewed-by: Alex Bennée
Signed-off-by: David Hildenbrand
Message-Id: <20190416185301.25344-2-da...@redhat.com>
Signed-off-by:
Reviewed-by: Alex Bennée
Reviewed-by: David Hildenbrand
Signed-off-by: Richard Henderson
---
tcg/tcg-op-vec.c | 49
1 file changed, 33 insertions(+), 16 deletions(-)
diff --git a/tcg/tcg-op-vec.c b/tcg/tcg-op-vec.c
index 27f65600c3..cfb18682b1
Changes since v2 (stsquad review):
* Split out a tcg/arm/ change to tcg_out_mov.
* Add some additional commentary for tcg_reg_alloc_foo.
Patches missing ack/review:
0006-tcg-arm-Use-tcg_out_mov_reg-in-tcg_out_mov.patch (new)
0010-tcg-Manually-expand-INDEX_op_dup_vec.patch
The ignored blocks are not migrated and those ranges are not used.
Signed-off-by: Wei Yang
---
exec.c | 4 +++-
include/exec/ram_addr.h | 2 ++
migration/ram.c | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index
On Fri, May 3, 2019 at 9:26 PM Alistair wrote:
>
> On Thu, May 2, 2019, at 3:06 AM, Peter Maydell wrote:
> > On Tue, 30 Apr 2019 at 21:29, Alistair Francis wrote:
> > >
> > > On Tue, Apr 30, 2019 at 9:02 AM Peter Maydell
> > > wrote:
> > > > Can you explain the purpose of the reset code? None
On 5/3/19 2:04 PM, Peter Maydell wrote:
> Currently the dc_zva helper function uses a variable length
> array. In fact we know (as the comment above remarks) that
> the length of this array is bounded because the architecture
> limits the block size and QEMU limits the target page size.
> Use a
On Thu, May 2, 2019, at 3:06 AM, Peter Maydell wrote:
> On Tue, 30 Apr 2019 at 21:29, Alistair Francis wrote:
> >
> > On Tue, Apr 30, 2019 at 9:02 AM Peter Maydell
> > wrote:
> > > Can you explain the purpose of the reset code? None of the other
> > > v7m boards seem to need to do a manual
On 5/3/19 10:13 AM, Peter Maydell wrote:
> Since Linux v3.17, the kernel's Image header includes a field image_size,
> which gives the total size of the kernel including unpopulated data
> sections such as the BSS). If this is present, then return it from
> load_aarch64_image() as the true size of
On 31.03.19 13:17, Alberto Garcia wrote:
> bdrv_unref_child() does the following things:
>
> - Updates the child->bs->inherits_from pointer.
> - Calls bdrv_detach_child() to remove the BdrvChild from bs->children.
> - Calls bdrv_unref() to unref the child BlockDriverState.
>
> When
On Fri, May 03, 2019 at 03:24:06PM -0500, Eric Blake wrote:
> On 5/3/19 2:31 PM, Ernest Esene wrote:
> > Add support for Linux I2C character device for I2C device passthrough
> > For example:
> > -chardev linux-i2c,address=0x46,path=/dev/i2c-N,id=i2c-chardev
> >
> > Signed-off-by: Ernest Esene
>
On Fri, May 03, 2019 at 06:00:11PM -0300, Eduardo Habkost wrote:
> On Fri, May 03, 2019 at 06:41:43PM +0200, Thomas Huth wrote:
> > On 03/05/2019 02.41, Eduardo Habkost wrote:
> > > From: Daniel P. Berrangé
> > >
> > > Unless overridden via an env var or configure arg, QEMU will only look
> > >
On Fri, May 3, 2019, 23:21 Eric Blake wrote:
> On 5/2/19 11:37 PM, Thomas Huth wrote:
> > On 02/05/2019 23.56, Eric Blake wrote:
> >> On 4/28/19 10:18 AM, Thomas Huth wrote:
> >>> QEMU iotest 175 is failing for me when I run it with -raw:
> >>>
> >>
> >>> == creating image with default
On 5/3/19 4:38 AM, Alberto Garcia wrote:
> The standard cluster descriptor in L2 table entries has a field to
> store the host cluster offset. When we need to get that offset from an
> entry we use L2E_OFFSET_MASK to ensure that we only use the bits that
> belong to that field.
>
> But while that
On Fri, May 03, 2019 at 06:41:43PM +0200, Thomas Huth wrote:
> On 03/05/2019 02.41, Eduardo Habkost wrote:
> > From: Daniel P. Berrangé
> >
> > Unless overridden via an env var or configure arg, QEMU will only look
> > for the 'python' binary in $PATH. This is unhelpful on distros which
> > are
On 5/2/19 11:43 PM, Thomas Huth wrote:
> On 03/05/2019 00.02, Eric Blake wrote:
>> On 4/28/19 10:21 AM, Thomas Huth wrote:
>>> QEMU iotest 221 is failing for me, too, when I run it with -raw:
>>
>> Which filesystem?
>
> ext4 again.
>
> $ stat -f /home/thuth/tmp/qemu-build/tests/qemu-iotests/
>
On Fri, May 03, 2019 at 04:49:05PM +0100, Daniel P. Berrangé wrote:
> On Fri, May 03, 2019 at 05:46:13PM +0200, Kashyap Chamarthy wrote:
> > When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
> > source of entropy, and that source needs to be "non-blocking", like
> >
On 5/3/19 2:31 PM, Ernest Esene wrote:
> Add support for Linux I2C character device for I2C device passthrough
> For example:
> -chardev linux-i2c,address=0x46,path=/dev/i2c-N,id=i2c-chardev
>
> Signed-off-by: Ernest Esene
> ---
Just an interface review:
> +++ b/qapi/char.json
> @@ -240,6
On Fri, May 03, 2019 at 04:00:33PM -0400, Michael S. Tsirkin wrote:
> On Mon, Apr 29, 2019 at 11:55:56AM -0300, Eduardo Habkost wrote:
> > irqchip=split and irqchip=kernel aren't guest ABI compatible, are
> > they?
>
> Can you remind me why they aren't?
We have the code introduced by patch 3/3
On 5/2/19 11:37 PM, Thomas Huth wrote:
> On 02/05/2019 23.56, Eric Blake wrote:
>> On 4/28/19 10:18 AM, Thomas Huth wrote:
>>> QEMU iotest 175 is failing for me when I run it with -raw:
>>>
>>
>>> == creating image with default preallocation ==
>>> Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT
On Mon, Apr 29, 2019 at 11:55:56AM -0300, Eduardo Habkost wrote:
> irqchip=split and irqchip=kernel aren't guest ABI compatible, are
> they?
Can you remind me why they aren't?
> --
> Eduardo
Python 2 will reach end of life in January 1 2020. Declare it as
deprecated.
Signed-off-by: Eduardo Habkost
---
configure| 8
qemu-deprecated.texi | 8
2 files changed, 16 insertions(+)
diff --git a/configure b/configure
index 5b183c2e39..50385061ed 100755
---
Richard Henderson writes:
> On 4/30/19 9:52 AM, Alex Bennée wrote:
>> I've also moved the existing system memory test and made it multiarch
>> and added the bootstrapping for aarch64 system tests. I would like to
>> add support for Big Endian as well but I didn't want to delay the
>> posting
Add support for Linux I2C character device for I2C device passthrough
For example:
-chardev linux-i2c,address=0x46,path=/dev/i2c-N,id=i2c-chardev
Signed-off-by: Ernest Esene
---
chardev/Makefile.objs | 1 +
chardev/char-i2c.c | 142 +
On 5/2/19 7:33 AM, Yoshinori Sato wrote:
> +/* conditional branch helper */
> +static void rx_bcnd_main(DisasContext *ctx, int cd, int dst)
> +{
> +DisasCompare dc;
> +TCGLabel *t, *done;
> +
> +switch (cd) {
> +case 0 ... 13:
> +dc.temp = tcg_temp_new();
> +
> (ping)
>
> Is there anything else I can do to help to get this merged?
>
> https://patchew.org/QEMU/20190423110034.1260142-1-jakub.jer...@kernkonzept.com/
Hello, Jakub.
I will be reviewing your patch next week, please be patient. In any case,
thanks for
your involving in solving this issue!
On Mon, Apr 29, 2019 at 09:22:12AM -0600, Alex Williamson wrote:
[...]
> > > What's a good 4.0.1 strategy to resolve this? Re-instate KVM irqchip
> > > as the Q35 default? I can't see that simply switching to current QEMU
> > > handling is a viable option for performance? What about 4.1? We
On 5/3/19 8:27 AM, Alex Bennée wrote:
>
> Yoshinori Sato writes:
>
>> Some RX peripheral using 8bit and 16bit registers.
>> Added 8bit and 16bit APIs.
>
> Doesn't this mean the build breaks at some point? Features used by other
> patches should be introduced first so the build remains
On 5/2/19 7:34 AM, Yoshinori Sato wrote:
> +static int32_t li(DisasContext *ctx, int sz)
> +{
> +int32_t addr;
> +bfd_byte buf[4];
> +addr = ctx->addr;
> +
> +switch (sz) {
> +case 1:
> +ctx->addr += 1;
> +ctx->dis->read_memory_func(addr, buf, 1, ctx->dis);
> +
On Sat, Apr 27, 2019 at 03:56:42PM +0200, Philippe Mathieu-Daudé wrote:
> When writing a new board, adding device which uses other devices
> (container) or simply refactoring, one can discover the hard way
> his machine misses some devices. In the case of containers, the
> error is not obvious:
>
On Fri, Apr 26, 2019 at 02:32:51PM +, Janakarajan Natarajan wrote:
> On 4/26/19 7:29 AM, Igor Mammedov wrote:
[...]
> >> diff --git a/numa.c b/numa.c
> >> index 3875e1efda..08601366c5 100644
> >> --- a/numa.c
> >> +++ b/numa.c
> > looks like wrong file to put RAMBlock code in. I though that we
On 5/2/19 7:10 AM, David Hildenbrand wrote:
> Mostly courtesy of Richard H.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/insn-data.def | 2 ++
> target/s390x/translate_vx.inc.c | 34 +
> 2 files changed, 36 insertions(+)
Reviewed-by: Richard
Hi Paolo,
That will be great, I would like to hear more details about the design and
implementation once you get those ready.
Thanks a lot,
Wei
On 5/3/19, 11:05 AM, "Paolo Bonzini" wrote:
On 03/05/19 10:21, Wei Li wrote:
> Got it, thanks Stefan for your clarification!
Hi
On 03/05/19 10:21, Wei Li wrote:
> Got it, thanks Stefan for your clarification!
Hi Wei,
Stefan and I should be posting a patch to add Linux SCSI driver
batching, and an implementation for virtio-scsi.
Paolo
> Wei
>
> On 5/1/19, 9:36 AM, "Stefan Hajnoczi" wrote:
>
> On Mon, Apr 29,
From: Neng Chen
Add support for getting and setting extended private flags of a
network device via SIOCSIFPFLAGS and SIOCGIFPFLAGS ioctls.
The ioctl numeric values are platform-independent and determined by
the file include/uapi/linux/sockios.h in Linux kernel source code:
#define
From: Neng Chen
Add support for options IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMPEMBERSHIP
of the syscall setsockopt(). These options control membership in
multicast groups. Their argument is a pointer to a struct ipv6_mreq,
which is in turn defined as:
struct ipv6_mreq {
/* IPv6 multicast
From: Daniel Santos
Sanitize interp_info structure in load_elf_binary() and, for MIPS only,
init its field fp_abi to MIPS_ABI_FP_UNKNOWN. This fixes appearances of
"Unexpected FPU mode" message in some MIPS use cases. Currently, this
bug is a complete stopper for some MIPS binaries.
In
From: Aleksandar Markovic
Fix support for the SIOCATMARK and SIOCGPGRP ioctls for xtensa by
correcting corresponding macro definition.
Values for TARGET_SIOCATMARK and TARGET_SIOCGPGRP are determined by
Linux kernel. Following relevant lines (obtained by grep) are from
the kernel source tree:
From: Aleksandar Markovic
Add support for setting the process (or process group) to receive SIGIO
or SIGURG signals when I/O becomes possible or urgent data is available,
using SIOCSPGRP ioctl.
The ioctl numeric values for SIOCSPGRP are platform-dependent and are
determined by following files
From: Aleksandar Markovic
This is a collection of misc patches for Linux user that I recently
accumulated from variuous sources. All of them originate from problems
observed on mips target. However, these changes actually affect and fix
problems on multiple targets.
v3->v4:
- improved commit
Antonio has submitted a patchset here:
https://patchew.org/QEMU/20190503082728.16485-1-...@ao2.it/
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On Fri, 3 May 2019 at 18:13, Peter Maydell wrote:
>
> We currently put the initrd at the smaller of:
> * 128MB into RAM
> * halfway into the RAM
> (with the dtb following it).
>
> However for large kernels this might mean that the kernel
> overlaps the initrd. For some kinds of kernel
On Fri, May 03, 2019 at 10:04:10AM +0100, Alex Bennée wrote:
> Stefan Hajnoczi writes:
> > +Isolation mechanisms
> > +
> > +Several isolation mechanisms are available to realize this architecture of
> > +guest isolation and the principle of least privilege. With the exception
On Fri, May 03, 2019 at 11:35:29AM +0100, Daniel P. Berrangé wrote:
> On Fri, May 03, 2019 at 11:28:53AM +0100, Peter Maydell wrote:
> > On Fri, 3 May 2019 at 11:19, Daniel P. Berrangé wrote:
> > > Everything above here is useful to QEMU devs, app devs & end users and
> > > should be made part of
I've submitted a patchset which I think should fix this, but if you
could test that it actually does handle large images correctly that
would be great.
https://patchew.org/QEMU/20190503171347.13747-1-peter.mayd...@linaro.org/
** Changed in: qemu
Status: New => In Progress
--
You
On 5/3/19 6:13 AM, Peter Maydell wrote:
> On Sat, 13 Apr 2019 at 08:07, Richard Henderson
>> This one does do the right thing, but better to clear the bits on write to
>> NSACR. This lets you avoid the change to fp_exception_el, and the missing
>> change to sve_exception_el.
>
> Hi Richard -- I
On Fri, May 3, 2019 at 12:30 PM Stefano Garzarella wrote:
>
> RBD APIs don't allow us to write more than the size set with
> rbd_create() or rbd_resize().
> In order to support growing images (eg. qcow2), we resize the
> image before write operations that exceed the current size.
>
>
From: Aleksandar Markovic
Fix support for the SIOCATMARK and SIOCGPGRP ioctls for xtensa by
correcting corresponding macro definition.
Values for TARGET_SIOCATMARK and TARGET_SIOCGPGRP are determined by
Linux kernel. Following relevant lines are from kernel source tree:
Since Linux v3.17, the kernel's Image header includes a field image_size,
which gives the total size of the kernel including unpopulated data
sections such as the BSS). If this is present, then return it from
load_aarch64_image() as the true size of the kernel rather than
just using the size of
Gotcha, thanks for the tip!
Best regards,
Boxuan Li
On Sat, May 4, 2019 at 1:00 AM Alex Bennée wrote:
>
> LI, BO XUAN writes:
>
> > Hi Alex,
> >
> > Sorry about that, I am still trying to get familiar with the patch
> > submission process. Since my patch has been changed from your last
>
Commit 463e0be10 ('blockjob: add AioContext attached callback') tried to
make block jobs robust against AioContext changes of their main node,
but it never made sure that the job coroutine actually runs in the new
thread.
Instead of waking up the job coroutine in whatever thread it ran before,
From: Neng Chen
Add support for options IPV6_ADD_MEMBERSHIP and IPV6_ADD_MEMBERSHIP
of the syscall setsockopt(). These options control membership in
multicast groups. Their argument is a pointer to a struct ipv6_mreq,
which is in turn defined as:
struct ipv6_mreq {
/* IPv6 multicast address
Kevin Wolf (2):
blockjob: Fix coroutine thread after AioContext change
test-block-iothread: Job coroutine thread after AioContext switch
job.c | 2 +-
tests/test-block-iothread.c | 107
2 files changed, 108 insertions(+), 1
This tests that a job coroutine always runs in the right iothread after
the AioContext of its main node has changed.
Signed-off-by: Kevin Wolf
---
tests/test-block-iothread.c | 107
1 file changed, 107 insertions(+)
diff --git a/tests/test-block-iothread.c
This patchset attempts to fix https://bugs.launchpad.net/qemu/+bug/1823998
which reports that we don't handle kernels larger than 128MB
correctly, because we allow the initrd to be placed over the
tail end of the kernel. AArch64 kernel Image files (since v3.17)
report the total size they require
From: Aleksandar Markovic
Add support for setting the process (or process group) to receive SIGIO
or SIGURG signals when I/O becomes possible or urgent data is available,
using SIOCSPGRP ioctl.
The ioctl numeric values for SIOCSPGRP are platform-dependent and are
determined by following files
On 10/12/2018 17:56, Peter Maydell wrote:
This patchset converts the m68k target from the deprecated
unassigned_access hook to the new transaction_failed hook.
It's RFC for a couple of reasons:
* it's untested, since I don't have an m68k test image
* the second patch just makes "bus error
We currently put the initrd at the smaller of:
* 128MB into RAM
* halfway into the RAM
(with the dtb following it).
However for large kernels this might mean that the kernel
overlaps the initrd. For some kinds of kernel (self-decompressing
32-bit kernels, and ELF images with a BSS section at
From: Neng Chen
Add support for setting and getting extended (private) flags of a
network device via SIOCSIFPFLAGS and SIOCGIFPFLAGS ioctls.
The ioctl numeric value is platform-independent and determined by
the file include/uapi/linux/sockios.h in Linux kernel source code:
#define
From: Aleksandar Markovic
This is a collection of misc patches for Linux user that I recently
accumulated from variuous sources. All of them originate from problems
observed on mips target. However, these changes actually affect and fix
problems on multiple targets.
v1->v2:
- updated and
From: Daniel Santos
Sanitize interp_info structure in load_elf_binary() and, for MIPS only,
init its field fp_abi to MIPS_ABI_FP_UNKNOWN. This fixes appearances of
"Unexpected FPU mode" message in some MIPS use cases. Currently, this
bug is a complete stopper for some MIPS binaries.
In
Richard Henderson writes:
> This provides the bootstrap and low level helper functions for an
> alpha kernel. We use direct access to the DP264 serial port for
> test output, and hard machine halt to exit the emulation.
Queued to testing/next, thanks.
I've also added tests/tcg/alpha/system/
On 5/3/19 6:41 PM, Thomas Huth wrote:
> On 03/05/2019 02.41, Eduardo Habkost wrote:
>> From: Daniel P. Berrangé
>>
>> Unless overridden via an env var or configure arg, QEMU will only look
>> for the 'python' binary in $PATH. This is unhelpful on distros which
>> are only shipping Python 3.x (eg
net_client_init() uses a variable length array to store the prefix
of 'ipv6-net' parameter (e.g. if ipv6-net=fec0::0/64, the prefix
is 'fec0::0').
Since the IPv6 prefix can be at most as long as an IPv6 address,
we can use an array with fixed size equals to INET6_ADDRSTRLEN.
Signed-off-by:
LI, BO XUAN writes:
> Hi Alex,
>
> Sorry about that, I am still trying to get familiar with the patch
> submission process. Since my patch has been changed from your last review,
> I thought it would be safe to not include the r-b tag from last time. Will
> take care next time!
That's ok. As
On 5/3/19 6:42 PM, Alex Bennée wrote:
>
> Gerd Hoffmann writes:
>
>> Based on the ubuntu.docker file.
>> Used to reproduce the build failure Peter was seeing.
>> Others might find this useful too ;)
>>
>> Signed-off-by: Gerd Hoffmann
>> ---
>> tests/docker/dockerfiles/ubuntu1804.docker | 57
On Fri, May 03, 2019 at 05:54:35PM +0100, Daniel P. Berrangé wrote:
> On Fri, May 03, 2019 at 06:41:43PM +0200, Thomas Huth wrote:
> > On 03/05/2019 02.41, Eduardo Habkost wrote:
> > > From: Daniel P. Berrangé
> > >
> > > Unless overridden via an env var or configure arg, QEMU will only look
> >
On 10/12/2018 17:56, Peter Maydell wrote:
Switch the m68k target from the old unassigned_access hook
to the transaction_failed hook.
The notable difference is that rather than it being called
for all physical memory accesses which fail (including
those made by DMA devices or by the gdbstub), it
On Fri, May 03, 2019 at 06:41:43PM +0200, Thomas Huth wrote:
> On 03/05/2019 02.41, Eduardo Habkost wrote:
> > From: Daniel P. Berrangé
> >
> > Unless overridden via an env var or configure arg, QEMU will only look
> > for the 'python' binary in $PATH. This is unhelpful on distros which
> > are
** Tags added: arm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823998
Title:
qemu-system-aarch64: support kernels bigger than 128MiB
Status in QEMU:
New
Bug description:
Presently QEMU
On 10/12/2018 17:56, Peter Maydell wrote:
In get_physical_address(), use address_space_ldl() and
address_space_stl() instead of ldl_phys() and stl_phys().
This allows us to check whether the memory access failed.
For the moment, we simply return -1 in this case;
add a TODO comment that we should
Gerd Hoffmann writes:
> Based on the ubuntu.docker file.
> Used to reproduce the build failure Peter was seeing.
> Others might find this useful too ;)
>
> Signed-off-by: Gerd Hoffmann
> ---
> tests/docker/dockerfiles/ubuntu1804.docker | 57 ++
> 1 file changed, 57
On 03/05/2019 02.41, Eduardo Habkost wrote:
> From: Daniel P. Berrangé
>
> Unless overridden via an env var or configure arg, QEMU will only look
> for the 'python' binary in $PATH. This is unhelpful on distros which
> are only shipping Python 3.x (eg Fedora) in their default install as,
> if
Your patch is now in git master as commit ef5dae6805cce7b59d129 --
thanks!
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1825359
The fix should now be in git master (commits 8b86d6d25807e13a6 and
6e6c4efed995d9ec), so it will be in the 4.1 release.
** Changed in: qemu
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On Fri, May 3, 2019 at 2:24 AM Daniel P. Berrangé wrote:
>
> On Fri, May 03, 2019 at 12:42:04AM +, Alistair Francis wrote:
> > Fix this build warning with GCC 9 on Fedora 30:
> > hw/usb/hcd-xhci.c:3339:66: error: ‘%d’ directive output may be truncated
> > writing between 1 and 10 bytes into
On 10/12/2018 17:56, Peter Maydell wrote:
In dump_address_map(), use address_space_ldl() instead of ldl_phys().
This allows us to check whether the memory access failed.
Signed-off-by: Peter Maydell
---
target/m68k/helper.c | 22 +++---
1 file changed, 15 insertions(+), 7
This patch introduces variable length suffixes for being used for inode mapping
instead of the fixed 16 bit size prefixes of patch 1. With this patch the inode
numbers on guest will typically be much smaller (e.g. around >2^1 .. >2^7
instead of >2^48 with patch 1).
I preserved both solutions in
Hi Alex,
Sorry about that, I am still trying to get familiar with the patch
submission process. Since my patch has been changed from your last review,
I thought it would be safe to not include the r-b tag from last time. Will
take care next time!
Best regards,
Boxuan Li
On Sat, May 4, 2019 at
RBD APIs don't allow us to write more than the size set with
rbd_create() or rbd_resize().
In order to support growing images (eg. qcow2), we resize the
image before write operations that exceed the current size.
Signed-off-by: Stefano Garzarella
---
v2:
- use bs->total_sectors instead of
On 5/3/19 5:56 PM, Marc-André Lureau wrote:
> Hi
>
> Le ven. 3 mai 2019 à 17:23, Peter Maydell a
> écrit :
>
>> On Fri, 3 May 2019 at 06:07, Thomas Huth wrote:
>>>
>>> On 03/05/2019 02.36, Cao Jiaxi wrote:
gcc_struct is for x86 only, and it generates an warning on ARM64
>> Clang/MinGW
Got it, thanks Stefan for your clarification!
Wei
On 5/1/19, 9:36 AM, "Stefan Hajnoczi" wrote:
On Mon, Apr 29, 2019 at 10:56:31AM -0700, Wei Li wrote:
>Does this mean the performance could be improved via adding Batch I/O
submission support in Guest driver side which will be able to
This patch aims to keep QID path identical beyond the scope of reboots and
guest suspensions. With the 1st patch alone the QID path of the same files
might change after reboots / suspensions, since 9p would restart with
empty qpp_table and the resulting QID path depends on the precise sequence
of
Addresses trivial changes regarding the previous patch as requested
on the mailing list a while ago.
* Removed unneccessary parantheses:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02661.html
* Removed unneccessary g_malloc() result checks:
Hi!
This is v2 of a proposed patch set for fixing file ID collisions with 9pfs.
Patch 1 to 3 are identical to the previous version. New in this v2 is patch 4
which introduces variable length suffixes for inode mapping instead of fixed
length prefixes.
Also: patch 4 disables file ID persistency
This first patch here is an updated version of Antonios Motakis'
original 4-patch set, merged to one patch:
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
* Updated to latest git master, specifically to new qht interface.
* Merged the original 4 patches to this single
On 4/8/19 10:12 PM, Marc-André Lureau wrote:
> The GCC9 compiler complains about QXL code that takes the address of
> members of the 'struct QXLReleaseRing' which is marked packed:
>
> CC hw/display/qxl.o
> /home/elmarco/src/qemu/hw/display/qxl.c: In function ‘init_qxl_ram’:
>
Boxuan Li writes:
> Use traces for debug message and qemu_log_mask for errors.
>
> Signed-off-by: Boxuan Li
You didn't add my r-b tags from last time. Anyway:
Reviewed-by: Alex Bennée
> ---
> v1: https://patchew.org/QEMU/20190428110258.86681-1-libox...@connect.hku.hk/
> v2:
Thomas Huth writes:
> On 03/05/2019 16.39, Alex Bennée wrote:
>> This attempts to clean-up the output to better match the output of the
>> rest of the QEMU check system. This includes:
>>
>> - formatting as " TESTiotest: nnn"
>> - calculating time diff at the end
>> - only dumping
Yoshinori Sato writes:
> Hello.
> This patch series is added Renesas RX target emulation.
I think the series is almost there - it's mostly just nits and clean
build fixes to sort out now. If you run the branch through CI you will
see where things fail to build.
However once that is all
On Fri, May 03, 2019 at 05:46:13PM +0200, Kashyap Chamarthy wrote:
> When QEMU exposes a VirtIO-RNG device to the guest, that device needs a
> source of entropy, and that source needs to be "non-blocking", like
> `/dev/urandom`. However, currently QEMU defaults to the problematic
> `/dev/random`,
Yoshinori Sato writes:
> Signed-off-by: Yoshinori Sato
> ---
> target/rx/gdbstub.c | 112
>
> target/rx/monitor.c | 38
> target/rx/Makefile.objs | 11 +
> 3 files changed, 161 insertions(+)
> create mode
1 - 100 of 268 matches
Mail list logo
