On 2/21/2020 7:31 PM, Stefan Hajnoczi wrote:
> On Thu, Feb 13, 2020 at 09:28:07AM +0800, pannengy...@huawei.com wrote:
>> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
>> index 2eba8b9db0..ed6a5cc03b 100644
>> --- a/hw/block/vhost-user-blk.c
>> +++
On 22/02/20 03:10, Chen Gang wrote:
> Set C1 to 1 if stack overflow occurred; set to 0 otherwise".
>
> In helper_fxam_ST0, I guess, we need "env->fpus |= 0x200" (but I don't
> know wheter it will be conflict with SIGND(temp)). And we have to still
> need foverflow, because all env->fptags being 0
[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/1814420
Title:
[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/1719282
Title:
Unable to
On Fri, Feb 21, 2020 at 6:53 PM Bin Meng wrote:
>
> On Sat, Feb 22, 2020 at 3:51 AM Alistair Francis wrote:
> >
> > On Thu, Feb 20, 2020 at 6:43 AM Bin Meng wrote:
> > >
> > > Update BIOS_FILENAME to consider 32-bit bios image file name.
> > >
> > > Tested booting Linux v5.5 32-bit image (built
On Sat, Feb 22, 2020 at 3:51 AM Alistair Francis wrote:
>
> On Thu, Feb 20, 2020 at 6:43 AM Bin Meng wrote:
> >
> > Update BIOS_FILENAME to consider 32-bit bios image file name.
> >
> > Tested booting Linux v5.5 32-bit image (built from rv32_defconfig
> > plus CONFIG_SOC_SIFIVE) with the default
On 2020/2/22 上午10:10, Chen Gang wrote:
> On 2020/2/22 上午12:18, Paolo Bonzini wrote:
>> On 21/02/20 15:09, Chen Gang wrote:
-/* XXX: test fptags too */
+if (env->fptags[env->fpstt]) {
+env->fpus |= 0x4100; /* Empty */
+return;
+}
+
>>> For
On 2020/2/22 上午12:18, Paolo Bonzini wrote:
> On 21/02/20 15:09, Chen Gang wrote:
>>> -/* XXX: test fptags too */
>>> +if (env->fptags[env->fpstt]) {
>>> +env->fpus |= 0x4100; /* Empty */
>>> +return;
>>> +}
>>> +
>> For fpop overflow, this fix is enough, but for me, we
> The chip docs don't mention any side effect, they only say that the
> DMA
> IRQ and Error bits in the bus master IDE status reg (bits 2 and 1)
> are
> write 1 to clear
I haven't found any documentation that mention that side effect either.
As you say, it only mentions that you should set the
This change allows us to set custom base address for guest programs. It is
needed to allow qemu to work with Thread Sanitizer (TSan), which has specific
boundary definitions for memory mappings on different platforms:
On Fri, Feb 21, 2020 at 2:08 PM Junaid Shahid wrote:
>
> On 2/20/20 9:34 AM, Ben Gardon wrote:
> >
> > FWIW, we currently do this eager splitting at Google for live
> > migration. When the log-dirty-memory flag is set on a memslot we
> > eagerly split all pages in the slot down to 4k granularity.
Patchew URL: https://patchew.org/QEMU/20200221214614.165338-1-yua...@google.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH] linux-user: Add an argument QEMU_MMAP_BASE to set custom mmap
base address in qemu user mode
On 2/20/20 9:34 AM, Ben Gardon wrote:
FWIW, we currently do this eager splitting at Google for live
migration. When the log-dirty-memory flag is set on a memslot we
eagerly split all pages in the slot down to 4k granularity.
As Jay said, this does not cause crippling lock contention because the
This change allows us to set custom base address for guest programs. It is
needed to allow qemu to work with Thread Sanitizer (TSan), which has specific
boundary definitions for memory mappings on different platforms:
Changes since v1:
- provided support for Bit 1 from PMRWBM register instead of Bit 0 to ensure
improved performance in virtualized environment [1] (Stefan)
- added check if pmr size is power of two in size (David)
- addressed cross compilation build problems reported by CI environment
This patch introduces support for PMR that has been defined as part of NVMe 1.4
spec. User can now specify a pmr_file which will be mmap'ed into qemu address
space and subsequently in PCI BAR 2. Guest OS can perform mmio read and writes
to the PMR region that will stay persistent accross system
This change adds the support for AT_EXECFN and AT_EXECFD auxval.
Signed-off-by: Lirong Yuan
---
linux-user/elfload.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index f3080a1635..7e0f3042f1 100644
---
On 2/21/20 12:32 PM, Stefan Hajnoczi wrote:
> Hi Andrzej,
> After having looked at the PMRWBM part of the spec, I think that the
> Bit 1 mode should be implemented for slightly better performance. Bit
> 0 mode is not well-suited to virtualization for the reasons I
> mentioned in the previous
On 2/21/20 11:45 AM, Dr. David Alan Gilbert wrote:
> Isn't there also a requirement that BARs are powers of two? Wouldn't
> you need to ensure the PMR file is a power of 2 in size?
>
> Dave
Agree, need to make sure it is power of 2.
On 2/21/20 4:17 AM, Peter Maydell wrote:
On Thu, 20 Feb 2020 at 16:22, Eric Blake wrote:
We are converting more doc files to *.rst rather than *.texi. Most
doc files are already listed early in diffs due to our catchall
docs/*, but a few top-level files get missed by that glob.
On 2/21/20 3:20 AM, Vladimir Sementsov-Ogievskiy wrote:
+static inline void warn_report_errp(Error **errp)
+{
+ assert(errp && *errp);
+ warn_report_err(*errp);
+ *errp = NULL;
+}
+
+
/*
* Just like error_setg(), except you get to specify the error class.
* Note: use of error
On 2/20/20 8:57 PM, Keqian Zhu wrote:
Currently, if the bytes_dirty_period is more than the 50% of
bytes_xfer_period, we start or increase throttling.
If we make this percentage higher, then we can tolerate higher
dirty rate during migration, which means less impact on guest.
The side effect of
On 2/21/20 3:42 AM, Vladimir Sementsov-Ogievskiy wrote:
+#define ERRP_AUTO_PROPAGATE() \
+ g_auto(ErrorPropagator) _auto_errp_prop = {.errp = errp}; \
+ errp = ((errp == NULL || *errp == error_fatal) \
+ ? &_auto_errp_prop.local_err
* BALATON Zoltan (bala...@eik.bme.hu) wrote:
> On Wed, 19 Feb 2020, BALATON Zoltan wrote:
> > faster or doing something differently? Does someone know what interrupts
> > are generated on real hardware in DMA mode so we can compare that to
> > what we see with QEMU?
>
> The document Programming
On Fri, 21 Feb 2020, Peter Maydell wrote:
On Fri, 21 Feb 2020 at 18:04, BALATON Zoltan wrote:
On Fri, 21 Feb 2020, Peter Maydell wrote:
I think that is the wrong approach. Enabling use of the host
FPU should not affect the accuracy of the emulation, which
should remain bitwise-correct. We
On Thu, Feb 20, 2020 at 6:43 AM Bin Meng wrote:
>
> Update BIOS_FILENAME to consider 32-bit bios image file name.
>
> Tested booting Linux v5.5 32-bit image (built from rv32_defconfig
> plus CONFIG_SOC_SIFIVE) with the default 32-bit bios image.
Do we really want to support a 32-bit sifive_u
On Thu, Feb 13, 2020 at 11:22 PM Anup Patel wrote:
>
> This patch extends Spike machine support to allow loading OpenSBI
> firmware (fw_jump.elf) separately using -bios option.
>
> Signed-off-by: Anup Patel
Can you add something in the commit message adding that you also
support adding an
On Thu, Feb 13, 2020 at 11:24 PM Anup Patel wrote:
>
> This patch adds an optional function pointer, "sym_cb", to
> riscv_load_firmware() which provides the possibility to access
> the symbol table during kernel loading.
>
> The pointer is ignored, if supplied with flat (non-elf) firmware image.
Hi Andrzej,
After having looked at the PMRWBM part of the spec, I think that the
Bit 1 mode should be implemented for slightly better performance. Bit
0 mode is not well-suited to virtualization for the reasons I
mentioned in the previous email.
The spec describes Bit 1 mode as "The completion
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Tue, Feb 18, 2020 at 03:48:11PM -0700, Andrzej Jakowski wrote:
> > This patch introduces support for PMR that has been defined as part of NVMe
> > 1.4
> > spec. User can now specify a pmr_file which will be mmap'ed into qemu
> > address
> >
-request' into staging
> (2020-02-20 17:35:42 +)
>
> are available in the Git repository at:
>
> https://gitlab.com/dagrh/qemu.git tags/pull-virtiofs-20200221
>
> for you to fetch changes up to 5bb8e8beedb47fc0d0a44957a154918c4f4afc80:
>
>
Hi Oksana,
On 2/14/20 12:52 PM, Oksana Vohchana wrote:
Adds functions to check if service RDMA is enabled and gets the interface
where it was configured
Signed-off-by: Oksana Vohchana
---
tests/acceptance/migration.py | 17 +
1 file changed, 17 insertions(+)
diff --git
On Tue, Feb 18, 2020 at 10:35:43AM +0100, Philippe Mathieu-Daudé wrote:
> Cc'ing Eduardo/Igor.
>
> On 2/18/20 9:48 AM, Luc Michel wrote:
> > On 2/17/20 12:45 PM, Philippe Mathieu-Daudé wrote:
> > >$ qemu-system-arm -M raspi1b -serial stdio \
> > >-kernel
On Fri, Feb 21, 2020, 17:50 Dr. David Alan Gilbert
wrote:
> * Stefan Hajnoczi (stefa...@gmail.com) wrote:
> > On Fri, Feb 21, 2020 at 3:36 PM Andrzej Jakowski
> > wrote:
> > > On 2/21/20 6:45 AM, Stefan Hajnoczi wrote:
> > > > Why is msync(2) done on memory loads instead of stores?
> > >
> > >
On Fri, 21 Feb 2020 at 18:09, Aleksandar Markovic
wrote:
> 1) Is ./configure --cc=clang the correct way to enable clang
> compilation of QEMU? Any other gotchas?
You'll also want "--cxx=clang++", so the (few) C++ parts of
QEMU get compiled with the same toolchain.
It should just work -- clang
On Fri, 21 Feb 2020 at 18:04, BALATON Zoltan wrote:
> On Fri, 21 Feb 2020, Peter Maydell wrote:
> > I think that is the wrong approach. Enabling use of the host
> > FPU should not affect the accuracy of the emulation, which
> > should remain bitwise-correct. We should only be using the
> > host
On 2/21/20 12:14 PM, Philippe Mathieu-Daudé wrote:
> On 2/21/20 11:56 AM, Stefan Hajnoczi wrote:
>> On Tue, Feb 11, 2020 at 10:51:19AM +, Stefan Hajnoczi wrote:
>>> On Mon, Feb 10, 2020 at 08:58:28PM +0100, Philippe Mathieu-Daudé wrote:
...
> [*] Test with the preset arduino examples (### TODO
On 21/02/20 14:14, Peter Maydell wrote:
> The initial case reported by Gavin in this thread is
> "-serial tcp:127.0.0.1:50900" with the other end being a program which
> listens on TCP port 50900 and then sleeps without accepting any incoming
> connections, which blocks the serial port output and
Hello, all
I have two questions:
1) Is ./configure --cc=clang the correct way to enable clang
compilation of QEMU? Any other gotchas?
2) Did somebody compare QEMU compiled by gcc vs. QEMU compiled with
clang (in any sense: executable size, performance, etc.)?
Thanks in advance,
Aleksandar
On Fri, 21 Feb 2020, Peter Maydell wrote:
On Fri, 21 Feb 2020 at 16:05, BALATON Zoltan wrote:
On Thu, 20 Feb 2020, Richard Henderson wrote:
On 2/18/20 9:10 AM, BALATON Zoltan wrote:
+DEFINE_PROP_BOOL("hardfloat", PowerPCCPU, hardfloat, true),
I would also prefer a different name here
On Fri, Feb 21, 2020 at 05:41:51PM +0100, David Hildenbrand wrote:
> I was now able to actually test resizing while migrating. I am using the
> prototype of virtio-mem to test (which also makes use of resizable
> allocations). Things I was able to reproduce:
The test cases cover quite a lot.
On 2/21/20 11:05 AM, Igor Mammedov wrote:
> On Thu, 13 Feb 2020 12:16:51 -0600
> Babu Moger wrote:
>
>> Initialize all the parameters in one function init_topo_info.
>
> is it possible to squash it in 2/16
>
Sure. We can do that.
>
>>
>> Move the data structure X86CPUTopoIDs and
* Stefan Hajnoczi (stefa...@gmail.com) wrote:
> On Fri, Feb 21, 2020 at 3:36 PM Andrzej Jakowski
> wrote:
> > On 2/21/20 6:45 AM, Stefan Hajnoczi wrote:
> > > Why is msync(2) done on memory loads instead of stores?
> >
> > This is my interpretation of NVMe spec wording with regards to PMRWBM
On Fri, 21 Feb 2020 at 17:31, Philippe Mathieu-Daudé wrote:
>
> To avoid orphean memory regions being added in the /unattached
("orphan")
> QOM container, use the memory_region_owner_nonnull.cocci script
> to set the correct ownership.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
>
21.02.2020 19:34, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
21.02.2020 10:38, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
Add functions to clean Error **errp: call corresponding Error *err
cleaning function an set pointer to NULL.
New functions:
On Fri, Feb 21, 2020 at 3:36 PM Andrzej Jakowski
wrote:
> On 2/21/20 6:45 AM, Stefan Hajnoczi wrote:
> > Why is msync(2) done on memory loads instead of stores?
>
> This is my interpretation of NVMe spec wording with regards to PMRWBM field
> which says:
>
> "The completion of a memory read from
To avoid orphean memory regions being added in the /unattached
QOM container, use the memory_region_owner_nonnull.cocci script
to set the correct ownership.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/riscv/sifive_e.c | 8
hw/riscv/sifive_u.c | 4 ++--
2 files changed, 6
To avoid orphean memory regions being added in the /unattached
QOM container, use the memory_region_owner_nonnull.cocci script
to set the correct ownership.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/exynos4210.c| 14 +++---
hw/arm/fsl-imx25.c | 14 +++---
To avoid orphean memory regions being added in the /unattached
QOM container, use the memory_region_owner_nonnull.cocci script
to set the correct ownership.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/display/cg3.c| 4 ++--
hw/display/g364fb.c | 5 +++--
hw/display/macfb.c | 4
To avoid orphean memory regions being added in the /unattached
QOM container, use the memory_region_owner_nonnull.cocci script
to set the correct ownership.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/dma/i8257.c | 2 +-
hw/dma/rc4030.c | 4 ++--
2 files changed, 3 insertions(+), 3
To avoid orphean memory regions being added in the /unattached
QOM container, use the memory_region_owner_nonnull.cocci script
to set the correct ownership.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/char/serial.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
To avoid orphean memory regions being added in the /unattached
QOM container, use the memory_region_owner_nonnull.cocci script
to set the correct ownership.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/core/platform-bus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
When a device creates a MemoryRegion without setting its ownership,
the MemoryRegion is added to the machine "/unattached" container in
the QOM tree.
Add a script to do automatically let the device take the ownership
of the memory regions it creates, and run it.
Philippe Mathieu-Daudé (7):
When a device creates a MemoryRegion without setting its ownership,
the MemoryRegion is added to the machine "/unattached" container in
the QOM tree.
Example with the Samsung SMDKC210 board:
$ arm-softmmu/qemu-system-arm -M smdkc210 -S -monitor stdio
(qemu) info qom-tree
/machine
On 18/02/20 21:38, Sunil Muthuswamy wrote:
> Signed-off-by: Sunil Muthuswamy
> ---
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1740a4fddc..9b3ba4e1b5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -404,6 +404,14 @@ S:
On 22.12.19 12:36, Alberto Garcia wrote:
> Hi,
>
> here's the new version of the patches to add subcluster allocation
> support to qcow2.
>
> Please refer to the cover letter of the first version for a full
> description of the patches:
>
>
On 22.12.19 12:37, Alberto Garcia wrote:
> Signed-off-by: Alberto Garcia
> ---
> tests/qemu-iotests/271 | 256 +
> tests/qemu-iotests/271.out | 208 ++
> tests/qemu-iotests/group | 1 +
> 3 files changed, 465 insertions(+)
>
On Thu, 13 Feb 2020 12:16:51 -0600
Babu Moger wrote:
> Initialize all the parameters in one function init_topo_info.
is it possible to squash it in 2/16
>
> Move the data structure X86CPUTopoIDs and X86CPUTopoInfo into
> x86.h.
A reason why it's moved should be here.
>
> Signed-off-by:
On 21/02/20 17:33, Philippe Mathieu-Daudé wrote:
> kvm_vm_ioctl() can fail, check its return value, and log an error
> when it failed. This fixes Coverity CID 1412229:
>
> Unchecked return value (CHECKED_RETURN)
>
> check_return: Calling kvm_vm_ioctl without checking return value
>
>
e8d460e2c6e87070807e0a02c0fec2:
>
> Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200221'
> into staging (2020-02-21 14:20:42 +)
>
> are available in the Git repository at:
>
> https://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull
On 22.12.19 12:37, 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
> ---
> block/qcow2.c | 19 ---
> 1 file changed, 12 insertions(+), 7
On Fri, Feb 21, 2020 at 5:11 PM Peter Maydell wrote:
>
> On Fri, 21 Feb 2020 at 16:05, BALATON Zoltan wrote:
> >
> > On Thu, 20 Feb 2020, Richard Henderson wrote:
> > > On 2/18/20 9:10 AM, BALATON Zoltan wrote:
> > >> +DEFINE_PROP_BOOL("hardfloat", PowerPCCPU, hardfloat, true),
> > >
> > > I
Kevin Wolf writes:
> Am 20.02.2020 um 17:01 hat Markus Armbruster geschrieben:
>> >> > void qmp_screendump(const char *filename, bool has_device, const char
>> >> > *device,
>> >> > bool has_head, int64_t head, Error **errp)
>> >> > {
>> >> > QemuConsole *con;
>> >>
On Fri, Feb 21, 2020 at 05:33:36PM +0100, Philippe Mathieu-Daudé wrote:
> kvm_vm_ioctl() can fail, check its return value, and log an error
> when it failed. This fixes Coverity CID 1412229:
>
> Unchecked return value (CHECKED_RETURN)
>
> check_return: Calling kvm_vm_ioctl without checking
On 22.12.19 12:37, Alberto Garcia wrote:
> Now that the implementation of subclusters is complete we can finally
> add the necessary options to create and read images with this feature,
> which we call "extended L2 entries".
>
> Signed-off-by: Alberto Garcia
> ---
> block/qcow2.c
We actually want to print the used_length, against which we check.
Cc: "Dr. David Alan Gilbert"
Cc: Juan Quintela
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
migration/multifd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/multifd.c
We never read or write beyond the used_length of memory blocks when
migrating. Make this clearer by using offset_in_ramblock() consistently.
Cc: "Dr. David Alan Gilbert"
Cc: Juan Quintela
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
migration/ram.c | 10 +-
1 file changed, 5
Resizing while migrating is dangerous and does not work as expected.
The whole migration code works on the usable_length of ram blocks and does
not expect this to change at random points in time.
In the case of postcopy, relying on used_length is racy as soon as the
guest is running. Also, when
When we partially change mappings (esp., mmap over parts of an existing
mmap like qemu_ram_remap() does) where we have a userfaultfd handler
registered, the handler will implicitly be unregistered from the parts that
changed.
Trying to place pages onto mappings where there is no longer a handler
Add two new helper functions. This will in come handy once we want to
handle ram block resizes while postcopy is active.
Cc: "Dr. David Alan Gilbert"
Cc: Juan Quintela
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
migration/ram.c | 54 -
1
Let's consolidate resetting the variables.
Cc: "Dr. David Alan Gilbert"
Cc: Juan Quintela
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
migration/ram.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index
Ram block notifiers are currently not aware of resizes. Especially to
handle resizes during migration, but also to implement actually resizeable
ram blocks (make everything between used_length and max_length
inaccessible), we want to teach ram block notifiers about resizeable
ram.
Introduce the
In case we grow our RAM after ram_postcopy_incoming_init() (e.g., when
synchronizing the RAM block state with the migration source), the resized
part would not get discarded. Let's perform that when being notified
about a resize while postcopy has been advised, but is not listening
yet. With
Let's make add/remove optional. We want to introduce a RAM block
notifier for RAM migration, that's only interested in resizes.
Reviewed-by: Peter Xu
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Eduardo Habkost
Cc: Marcel Apfelbaum
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
We want to make use of ram_block_discard_range() in the RAM block resize
callback when growing a RAM block, *before* used_length is changed.
Let's relax the check. We always have a reserved mapping for the whole
max_length, so we cannot corrupt unrelated data.
Cc: Richard Henderson
Cc: Paolo
Resizing while migrating is dangerous and does not work as expected.
The whole migration code works on the usable_length of ram blocks and does
not expect this to change at random points in time.
In the case of precopy, the ram block size must not change on the source,
after syncing the RAM block
Current code no longer needs these stubs to compile. Let's just remove
them.
Reviewed-by: Peter Xu
Cc: Richard Henderson
Cc: Paolo Bonzini
Cc: Eduardo Habkost
Cc: Peter Xu
Signed-off-by: David Hildenbrand
---
stubs/ram-block.c | 20
1 file changed, 20 deletions(-)
This is the follow up of
"[PATCH RFC] memory: Don't allow to resize RAM while migrating" [1]
This series contains some (slightly modified) patches also contained in:
"[PATCH v2 fixed 00/16] Ram blocks with resizable anonymous allocations
under POSIX" [2]
That series will be based on
Factor it out into common code when a new notifier is registered, just
as done with the memory region notifier. This allows us to have the
logic about how to process existing ram blocks at a central place (which
will be extended soon).
Just like when adding a new ram block, we have to register
Peter Maydell writes:
> On Thu, 20 Feb 2020 at 16:22, Eric Blake wrote:
>>
>> We are converting more doc files to *.rst rather than *.texi. Most
>> doc files are already listed early in diffs due to our catchall
>> docs/*, but a few top-level files get missed by that glob.
>>
>> Signed-off-by:
Hi Linus and Bartosz,
On Tue, Feb 18, 2020 at 4:18 PM Geert Uytterhoeven
wrote:
> GPIO controllers are exported to userspace using /dev/gpiochip*
> character devices. Access control to these devices is provided by
> standard UNIX file system permissions, on an all-or-nothing basis:
> either a
On 2/21/20 8:34 AM, Geert Uytterhoeven wrote:
> Hi Randy,
>
Hi Geert,
Those changes look good. Thanks.
--
~Randy
On 21/02/20 14:25, Philippe Mathieu-Daudé wrote:
> Following up "global exec/memory/dma APIs cleanup"
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg681475.html
>
> Few more cleanups in PCNET & SCSI ESP devices.
Can you send a pull request for everything?
Paolo
kvm_vm_ioctl() can fail, check its return value, and log an error
when it failed. This fixes Coverity CID 1412229:
Unchecked return value (CHECKED_RETURN)
check_return: Calling kvm_vm_ioctl without checking return value
Reported-by: Coverity (CID 1412229)
Fixes: 235e8982ad3 ("support using
On Fri, Feb 21, 2020 at 11:19:58AM +0100, David Hildenbrand wrote:
[...]
> Lol, man this code is confusing.
(Yes in many places it is...)
>
> So, migration_is_idle() really only checks current_migration, not
> current_incoming.
>
> I didn't expect to be knees deep in migration code at this
RFC 7230 section 3.2 indicates that whitespace is permitted between
the field name and field value and after the field value.
Signed-off-by: David Edmondson
---
block/curl.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/block/curl.c
Vladimir Sementsov-Ogievskiy writes:
> 21.02.2020 10:38, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> Add functions to clean Error **errp: call corresponding Error *err
>>> cleaning function an set pointer to NULL.
>>>
>>> New functions:
>>>error_free_errp
>>>
Hi Randy,
On Tue, Feb 18, 2020 at 7:30 PM Randy Dunlap wrote:
> On 2/18/20 7:18 AM, Geert Uytterhoeven wrote:
> > Document the GPIO Aggregator, and the two typical use-cases.
> >
> > Signed-off-by: Geert Uytterhoeven
> > --- /dev/null
> > +++
An HTTP object store of my acquaintance returns "accept-ranges: bytes"
(all lower case) as a header, causing the QEMU curl backend to refuse
to talk to it. RFC 7230 says that HTTP headers are case insensitive,
so update the curl backend accordingly.
At the same time, allow for arbitrary white
RFC 7230 section 3.2 indicates that HTTP header field names are case
insensitive.
Signed-off-by: David Edmondson
---
block/curl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/curl.c b/block/curl.c
index f9ffb7f4e2bf..1421e8fb9815 100644
--- a/block/curl.c
+++
Since commit d8ed887bdc, the puv3_intc_cpu_handler handler takes
a pointer to UniCore32CPU in its opaque argument. Directly pass
the cpu pointer.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/unicore32/puv3.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
Vladimir Sementsov-Ogievskiy writes:
> 21.02.2020 12:19, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
>>
>>> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
>>> functions with an errp OUT parameter.
>>>
>>> It has three goals:
>>>
>>> 1. Fix issue with
The fxam instruction returns the wrong result after fdecstp or after
an underflow. Check fptags to handle this.
Reported-by:
Signed-off-by: Paolo Bonzini
---
target/i386/fpu_helper.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/target/i386/fpu_helper.c
Since commit d8ed887bdc, the cpu_mips_irq_request handler takes
a pointer to MIPSCPU in its opaque argument. Directly pass the
cpu pointer.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/mips_int.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/mips/mips_int.c
v1->v2 changes: dropped the last 6 patches from rth as there's
a problem with one of them that's too complicated to try to
fix up.
thanks
-- PMM
The following changes since commit a8c6af67e1e8d460e2c6e87070807e0a02c0fec2:
Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200
On 21/02/20 15:09, Chen Gang wrote:
>> -/* XXX: test fptags too */
>> +if (env->fptags[env->fpstt]) {
>> +env->fpus |= 0x4100; /* Empty */
>> +return;
>> +}
>> +
> For fpop overflow, this fix is enough, but for me, we still need
> foverflow to check fpush/fld*_ST0
Patchew URL:
https://patchew.org/QEMU/20200221130740.7583-1-peter.mayd...@linaro.org/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
On Fri, 21 Feb 2020 at 16:05, BALATON Zoltan wrote:
>
> On Thu, 20 Feb 2020, Richard Henderson wrote:
> > On 2/18/20 9:10 AM, BALATON Zoltan wrote:
> >> +DEFINE_PROP_BOOL("hardfloat", PowerPCCPU, hardfloat, true),
> >
> > I would also prefer a different name here -- perhaps x-no-fp-fi.
>
>
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
wrote:
>
> We will eventually remove the early ARM_FEATURE_VFP test,
> so add a proper test for each trans_* that does not already
> have another ISA test.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
On Fri, 14 Feb 2020 at 18:15, Richard Henderson
wrote:
>
> We are going to convert FEATURE tests to ISAR tests,
> so FPSP needs to be set for these cpus, like we have
> already for FPDP.
>
> Signed-off-by: Richard Henderson
Reviewed-by: Peter Maydell
thanks
-- PMM
1 - 100 of 319 matches
Mail list logo
