Hi Cedric,
On [2019 Jan 21] Mon 17:00:02, Cédric Le Goater wrote:
> JEDEC STANDARD JESD216 for Serial Flash Discovery Parameters (SFDP)
> provides a mean to describe the features of a serial flash device
> using a set of internal parameter tables.
>
> This is the initial framework for the RDSFPD
On 29.01.19 12:39, Daniel P. Berrangé wrote:
> This is a few misc fixes identified after the icon location changes
> were merged. Most importantly it deals with the nsis installer file
> manifest.
>
> Daniel P. Berrangé (5):
> nsis: don't install files into /tmp
> make: don't insert a '/' afte
Eric Blake writes:
> On 1/31/19 2:08 PM, Yuval Shaia wrote:
>> On Thu, Jan 31, 2019 at 07:17:16AM -0600, Eric Blake wrote:
>>> On 1/31/19 7:08 AM, Yuval Shaia wrote:
Signed-off-by: Yuval Shaia
---
hmp-commands-info.hx | 14 ++
monitor.c| 6 ++
>>>
On 29.01.19 22:07, Eric Blake wrote:
> On 1/29/19 5:39 AM, Daniel P. Berrangé wrote:
>> The nsis installer target has to run 'make install' to populate a
>> directory tree with content for the package. Replace the current
>> usage of '/tmp/qemu-nsis' with a location underneath the build
>> director
On 29.01.19 12:39, Daniel P. Berrangé wrote:
> The code to set the -W64 flag is inside a conditional block that only
> executes when we are bundling DLLs with the installer. This results in
> QEMU being installed in the wrong location on 64-bit hosts when DLLs
> are not bundled.
>
> Signed-off-by:
David Hildenbrand writes:
> On 31.01.19 19:19, Markus Armbruster wrote:
>> David Hildenbrand writes:
>>
>>> From: Pankaj Gupta
>>>
>>> This is the current protoype of virtio-pmem. Support will require
>>> machine changes for the architectures that will support it, so it will
>>> not yet be com
macOS 10.14 deprecated NSOnState/NSOffState in favour of
NSControlStateValueOn/NSControlStateValueOff. Use the new constants,
and #define them to the old ones when compiling against a pre-10.13 SDK.
Also [NSGraphicsContext graphicsPort] is now deprecated, use
[NSGraphicsContext CGContext] when avai
On 2019-02-01 07:14, Thomas Huth wrote:
> On 2019-01-31 19:08, Paolo Bonzini wrote:
>> On 31/01/19 19:00, Thomas Huth wrote:
> (and the prototypes in the header) anymore, so if you try to compile s390x
> without CONFIG_PCI, the build currently fails.
>
Fixes: 468a93898a97 ("s390x/p
Patchew URL: https://patchew.org/QEMU/20190124010023.24397-1-phi...@redhat.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!
Patchew URL: https://patchew.org/QEMU/20190131071658.29120-1-tao3...@intel.com/
Hi,
This series failed the docker-mingw@fedora 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 ===
#!
Hi,
> > tar_file=$(realpath "$1")
> > -list_file="${tar_file}.list"
> > -vroot_dir="${tar_file}.vroot"
> > +sub_file=$(mktemp "${tar_file%.tar}.sub..tar")
> > +sub_tdir=$(mktemp -d "${tar_file%.tar}.sub.")
>
> mktemp is not specified by POSIX; and FreeBSD man pages for mktemp
>
On 2019-01-31 19:08, Paolo Bonzini wrote:
> On 31/01/19 19:00, Thomas Huth wrote:
(and the prototypes in the header) anymore, so if you try to compile s390x
without CONFIG_PCI, the build currently fails.
>>> Fixes: 468a93898a97 ("s390x/pci: pass the retaddr to all PCI instructions")
On Thu, Jan 31, 2019 at 03:31:51PM +0100, Kevin Wolf wrote:
> bdrv_co_invalidate_cache() clears the BDRV_O_INACTIVE flag before
> actually activating a node so that the correct permissions etc. are
> taken. In case of errors, the flag must be restored so that the next
> call to bdrv_co_invalidate_c
On Thu, Jan 31, 2019 at 02:38:10PM +0200, Alberto Garcia wrote:
> The cmd() method of the QEMUQtestProtocol class sends a qtest command
> to QEMU but doesn't wait for the return message ("OK", "FAIL", "ERR").
> Because of this, it can return control to the caller before the
> command has actually f
On Thu, Jan 31, 2019 at 11:32:32AM +, Fernando Casas Schössow wrote:
> Sorry for resurrecting this thread after so long but I just upgraded the host
> to Qemu 3.1 and libvirt 4.10 and I'm still facing this problem.
> At the moment I cannot use virtio disks (virtio-blk nor virtio-scsi) with my
It seems that this poor patch is left alone. :(
I sent all, but this patch failed to join them, so sorry for that..
Could we just let it be?
Have a nice day, thanks
Fei
在 2019/2/1 下午1:25, Fei Li 写道:
From: Fei Li
Supplement the error handling for touch_all_pages: add an Error
parameter for it
在 2019/2/1 下午1:18, Fei Li 写道:
From: Fei Li
Update qemu_thread_create()'s callers by
- setting an error on qemu_thread_create() failure for callers that
set an error on failure;
- reporting the error and returning failure for callers that return
an error code on failure;
- reporting the
From: Fei Li
Supplement the error handling for touch_all_pages: add an Error
parameter for it to propagate the error to its caller to do the
handling in case it fails.
Cc: Markus Armbruster
Signed-off-by: Fei Li
---
util/oslib-posix.c | 26 --
1 file changed, 16 insert
From: Fei Li
Update qemu_thread_create()'s callers by
- setting an error on qemu_thread_create() failure for callers that
set an error on failure;
- reporting the error and returning failure for callers that return
an error code on failure;
- reporting the error and setting some state for cal
On Thu, Jan 31, 2019 at 04:19:10PM +0100, Stefano Garzarella wrote:
> We add acct_failed param in order to use virtio_blk_handle_rw_error()
> also when is not required to call block_acct_failed(). (eg. a discard
> operation is failed)
>
> Signed-off-by: Stefano Garzarella
> ---
> hw/block/virtio
On 1/30/19 12:36 PM, Mark Cave-Ayland wrote:
> The current implementations make use of the endian-specific macros MRGLO/MRGHI
> and also reference HI_IDX and LO_IDX directly to calculate array offsets.
>
> Rework the implementation to use the Vsr* macros so that these per-endian
> references can b
From: Fei Li
Utilize the existed errp to propagate the error and do the
corresponding cleanup to replace the temporary &error_abort.
Cc: Markus Armbruster
Cc: Gerd Hoffmann
Signed-off-by: Fei Li
---
hw/usb/ccid-card-emulated.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletio
>> I think, the term "arch" is a little problematic in QEMU parlance. IMHO,
>> "target" should be used instead. ("arch" is used in Linux kernel community)
> Naming things is hard, so this is a valid discussion. But, I have to
> say that I also find "arch" in this context to be descriptive enough.
Hi,
This idea comes from BiteSizedTasks, and this patch series implement
the error checking of qemu_thread_create: make qemu_thread_create
return a flag to indicate if it succeeded rather than failing with
an error; make all callers check it.
The first patch modifies the qemu_thread_create() by p
From: Fei Li
qemu_thread_create() abort()s on error. Not nice. Give it a return
value and an Error ** argument, so it can return success/failure.
Considering qemu_thread_create() is quite widely used in qemu, split
this into two steps: this patch passes the &error_abort to
qemu_thread_create() e
From: Fei Li
For qemu_signalfd_compat: set errno, do some cleanup, and return
-1 to replace the temporary &error_abort when failing to create
sigwait_compat.
Cc: Markus Armbruster
Cc: Eric Blake
Signed-off-by: Fei Li
---
util/compatfd.c | 13 ++---
1 file changed, 10 insertions(+), 3
From: Fei Li
Add a local_err to hold the error, and return the corresponding
error code to replace the temporary &error_abort.
Cc: Markus Armbruster
Cc: David Gibson
Signed-off-by: Fei Li
Acked-by: David Gibson
---
hw/ppc/spapr_hcall.c | 12
1 file changed, 8 insertions(+), 4 d
From: Fei Li
Utilize the existed errp to propagate the error instead of the
temporary &error_abort.
Cc: Markus Armbruster
Cc: Marc-André Lureau
Signed-off-by: Fei Li
---
dump.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/dump.c b/dump.c
index e4886bc9c3..92cc277015
From: Fei Li
For iothread_complete: utilize the existed errp to propagate the
error and do the corresponding cleanup to replace the temporary
&error_abort.
Cc: Markus Armbruster
Cc: Stefan Hajnoczi
Cc: Eric Blake
Signed-off-by: Fei Li
---
iothread.c | 19 +--
1 file changed,
From: Fei Li
Supplement the error handling for vnc_thread_worker_thread: add
an Error parameter for it to propagate the error to its caller to
handle in case it fails, and make it return a Boolean to indicate
whether it succeeds.
Cc: Markus Armbruster
Cc: Gerd Hoffmann
Signed-off-by: Fei Li
-
From: Fei Li
Utilize the existed errp to propagate the error and do the
corresponding cleanup to replace the temporary &error_abort.
Cc: Markus Armbruster
Cc: Jiri Slaby
Signed-off-by: Fei Li
---
hw/misc/edu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/hw
From: Fei Li
The callers of qemu_init_vcpu() already passed the **errp to handle
errors. In view of this, add a new Error parameter to qemu_init_vcpu()
and all qemu_X_start_vcpu() functions called by qemu_init_vcpu() to
propagate the error and let the further callers check it.
Besides, make qemu
On Thu, Jan 31, 2019 at 04:19:14PM +0100, Stefano Garzarella wrote:
> If the WRITE_ZEROES feature is enabled, we check this command
> in the test_basic().
>
> Signed-off-by: Stefano Garzarella
> ---
> tests/virtio-blk-test.c | 60 +
> 1 file changed, 60 in
Sorry again! Please omit this email. It seems there's something wrong
with my send-email.. :(
Have a nice day
Fei
在 2019/2/1 下午1:09, Fei Li 写道:
Hi,
This idea comes from BiteSizedTasks, and this patch series implement
the error checking of qemu_thread_create: make qemu_thread_create
return a fl
On Thu, Jan 31, 2019 at 04:19:13PM +0100, Stefano Garzarella wrote:
> The size of data in the virtio_blk_request must be a multiple
> of 512 bytes for IN and OUT requests, or a multiple of the size
> of struct virtio_blk_discard_write_zeroes for DISCARD and
> WRITE_ZEROES requests.
>
> Signed-off-
Hi,
This idea comes from BiteSizedTasks, and this patch series implement
the error checking of qemu_thread_create: make qemu_thread_create
return a flag to indicate if it succeeded rather than failing with
an error; make all callers check it.
The first patch modifies the qemu_thread_create() by p
Patchew URL:
https://patchew.org/QEMU/20190125140017.6092-1-alex.ben...@linaro.org/
Hi,
This series failed the docker-mingw@fedora 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 =
On Thu, Jan 31, 2019 at 04:19:12PM +0100, Stefano Garzarella wrote:
> diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
> index 542ec52536..34ee676895 100644
> --- a/hw/block/virtio-blk.c
> +++ b/hw/block/virtio-blk.c
> @@ -147,6 +147,30 @@ out:
> aio_context_release(blk_get_aio_conte
在 2019/2/1 上午2:05, Markus Armbruster 写道:
I'm afraid you made a bit of a mess :)
"[PATCH for-4.0 00/11]" suggests this is v1 of eleven patches.
Awkward, I forgot the v10.. =-O
Fei Li writes:
Hi,
This idea comes from BiteSizedTasks, and this patch series implement
the error checking of qe
On Thu, Jan 31, 2019 at 04:19:11PM +0100, Stefano Garzarella wrote:
> In order to avoid migration issues, we enable DISCARD and
> WRITE ZEROES features only for machine type >= 4.0
Please use two separate properties that correspond to the
VIRTIO_BLK_F_DISCARD and VIRTIO_BLK_F_WRITE_ZEROES virtio-b
On 19/01/2019 01:07, Fabiano Rosas wrote:
> The upcoming single step functionality (KVM HV) needs to write to the
> Trace Interrupt handler's address for its mechanism to work. The
> address is calculated by applying an offset according to the value of
> the Alternate Interrupt Location (AIL) bi
On 01/02/2019 08:57, Fabiano Rosas wrote:
> Alexey Kardashevskiy writes:
>
>> On 31/01/2019 03:30, Fabiano Rosas wrote:
>>> Alexey Kardashevskiy writes:
>>>
but this is a register which does not have endianness, the endianness
appears here because the interface between gdb and
On Thu, Jan 31, 2019 at 03:12:48PM +0100, Thomas Huth wrote:
> On 2019-01-30 18:21, Philippe Mathieu-Daudé wrote:
> > On 1/30/19 5:39 PM, Thomas Huth wrote:
> >> These files don't use anything from m48t59.h, so no need to include
> >> this header here.
> >>
> >> Signed-off-by: Thomas Huth
> >> ---
On Fri, Feb 01, 2019 at 11:56:22AM +1100, Alexey Kardashevskiy wrote:
> reg->phys_hi and assigned->phys_hi are big endian but we do an extra
> byteswap anyway when copying reg->phys_hi to assigned->phys_hi.
> To make things slightly more messy, we also add a relocatable bit (b_n())
> although in th
On Thu, Jan 31, 2019 at 11:26:37PM +0300, Julia Suvorova wrote:
> The whitelist option allows to run a reduced monitor with a subset of
> QMP commands. This allows the monitor to run in secure mode, which is
> convenient for sending commands via the WebSocket monitor using the
> web UI. This is pla
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, February 1, 2019 7:55
> To: Alexandro Sanchez Bach ; 'Markus Armbruster'
>
> Cc: 'Peter Maydell' ; 'Peter Krempa'
> ; 'Qemu-block' ; 'Libvirt'
> ; 'QEMU Developers' ;
> 'László Érsek' ; 'Justin Terry
From: Steffen Görtz
The nRF51 contains three regions of non-volatile memory (NVM):
- CODE (R/W): contains code
- FICR (R): Factory information like code size, chip id etc.
- UICR (R/W): Changeable configuration data. Lock bits, Code
protection configuration, Bootloader address, Nordic SoftRadio
From: Steffen Görtz
Signed-off-by: Steffen Görtz
Signed-off-by: Stefan Hajnoczi
Acked-by: Thomas Huth
Reviewed-by: Peter Maydell
---
tests/microbit-test.c | 108 ++
1 file changed, 108 insertions(+)
diff --git a/tests/microbit-test.c b/tests/microbit-
From: Steffen Görtz
Instantiates UICR, FICR, FLASH and NVMC in nRF51 SOC.
Signed-off-by: Steffen Görtz
Reviewed-by: Peter Maydell
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Stefan Hajnoczi
---
include/hw/arm/nrf51_soc.h | 2 ++
hw/arm/nrf51_soc.c | 41 +++--
v4:
* assert(offset + size <= s->flash_size) [Peter]
v3:
* Fix endianness of s->storage[], tested by Joel Stanley on
big-endian ppc [Peter]
* Fix off-by-one that prevented clearing the last page of flash
* Add missing memory_region_flush_rom_device() call to flash_write()
v2:
* Add Patch 2
On 2019/1/30 下午1:48, Yongji Xie wrote:
On Wed, 30 Jan 2019 at 10:32, Jason Wang wrote:
On 2019/1/22 下午4:31, elohi...@gmail.com wrote:
+static int
+vu_queue_inflight_get(VuDev *dev, VuVirtq *vq, int desc_idx)
+{
+if (!has_feature(dev->protocol_features,
+VHOST_USER_PROTOCOL_F_INF
On 2019/1/30 上午11:58, Yongji Xie wrote:
On Wed, 30 Jan 2019 at 10:32, Jason Wang wrote:
On 2019/1/22 下午4:31, elohi...@gmail.com wrote:
+static int
+vu_queue_inflight_get(VuDev *dev, VuVirtq *vq, int desc_idx)
+{
+if (!has_feature(dev->protocol_features,
+VHOST_USER_PROTOCOL_F_IN
The lo,hi order is different from the comments. And in commit
1ec182c33379 ("target/arm: Convert to HAVE_CMPXCHG128"), it changes
the original code logic. So just restore the old code logic before this
commit:
do_paired_cmpxchg64_be():
cmpv = int128_make128(env->exclusive_high, env->exclusive_
[get|set]_addr are two counterpart to access PCDIMMDevice.addr.
Since we have already set up a property PC_DIMM_ADDR_PROP for this
field and use this mechanism in set_addr, it would be more proper to use
the same mechanism in set_addr.
This patch uses object_property_get_uint() to replace the dir
reg->phys_hi and assigned->phys_hi are big endian but we do an extra
byteswap anyway when copying reg->phys_hi to assigned->phys_hi.
To make things slightly more messy, we also add a relocatable bit (b_n())
although in the right endianness.
This fixes endianness of assigned->phys_hi.
This is unli
At the moment the rtas's Makefile uses generic QEMU rules which means
that when QEMU is compiled on a little endian system, the spapr-rtas.bin
is compiled as little endian too which is incorrect as it is always
executed in big endian mode.
This enforces -mbig by defining %.o:%.S rule as spapr-rtas
On 01/02/19 00:28, Alexandro Sanchez Bach wrote:
> (CC'd Yu Ning @ Intel's HAXM team)
>
> Not sure, if I'm understanding the issue correctly, but isn't
> `HAX_VM_IOCTL_SET_RAM2` with the `HAX_RAM_INFO_ROM` flag precisely
> what you are looking for?
>
> More precisely, HAX_VM_IOCTL_SET_RAM2 maps a
>> This is all greek to me. I take it there's something wrong with these
>> accelerators that makes (read-only?) flash memory not work, even
>> though the read-only mapping we now create for traditional BIOS works.
>> Weird, but I'm of course willing to take your word for it.
> Yes, as I wrot
On 1/31/19 5:07 AM, Peter Maydell wrote:
> The {IOE, DZE, OFE, UFE, IXE, IDE} bits in the FPSCR/FPCR are for
> enabling trapped IEEE floating point exceptions (where IEEE exception
> conditions cause a CPU exception rather than updating the FPSR status
> bits). QEMU doesn't implement this (and nor
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190122092909.5341-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PAT
On 31/01/19 13:12, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 31/01/19 10:41, Markus Armbruster wrote:
>>> Paolo Bonzini writes:
>>>
On 31/01/19 09:40, Markus Armbruster wrote:
>> Maybe we should just add pflash block properties to the machine? And
>> then it can crea
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v5 00/35] target/riscv: Convert to decodetree
Type: series
Message-id: 2019
On 1/31/19 3:22 AM, Peter Maydell wrote:
> Peter Maydell (5):
> hw/arm/boot: Fix block comment style in arm_load_kernel()
> hw/arm/boot: Factor out "direct kernel boot" code into its own
> function
> hw/arm/boot: Factor out "set up firmware boot" code
> hw/arm/boot: Clarify why arm_setu
On Thu, Jan 31, 2019 at 8:20 PM Kevin Wolf wrote:
> Rather than requiring that the external data file node is passed
> explicitly when creating the qcow2 node, store the filename in the
> designated header extension during .bdrv_create and read it from there
> as a default during .bdrv_open.
>
I
Patchew URL:
https://patchew.org/QEMU/1548410831-19553-1-git-send-email-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC PATCH v5 00/52] Support Kconfig in QEMU
Message-id: 1548410831-19553-1-git-s
Patchew URL:
https://patchew.org/QEMU/1548410831-19553-1-git-send-email-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1548410831-19553-1-git-send-email-pbonz...@redhat.com
Subject: [Qemu-devel] [R
On 1/31/19 11:14 PM, Paolo Bonzini wrote:
> On 31/01/19 22:22, Philippe Mathieu-Daudé wrote:
>> I kinda disagree with the SuperIO generated configs here, but partly my
>> fault because the previous Makefile.objs missed the CONFIG_ISA_SUPERIO
>> (I missed to review eae2e2e96bf from Thomas where is i
Patchew URL:
https://patchew.org/QEMU/1548410831-19553-1-git-send-email-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC PATCH v5 00/52] Support Kconfig in QEMU
Type: series
Message-id: 1548410831-
On 31/01/19 23:10, Philippe Mathieu-Daudé wrote:
> config SMBUS
> bool
> select I2C
>
> config SMBUS_EEPROM
> bool
> select SMBUS
>
> (or 'depends on')
Sure.
Paolo
On 31/01/19 22:22, Philippe Mathieu-Daudé wrote:
> I kinda disagree with the SuperIO generated configs here, but partly my
> fault because the previous Makefile.objs missed the CONFIG_ISA_SUPERIO
> (I missed to review eae2e2e96bf from Thomas where is introduced
> CONFIG_SMC37C669).
> So introducing
Patchew URL: https://patchew.org/QEMU/20190131202637.4062-1-jus...@mail.ru/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190131202637.4062-1-jus...@mail.ru
Subject: [Qemu-devel] [PATCH] monitor: Add whitelist suppor
On 31/01/19 22:23, Philippe Mathieu-Daudé wrote:
> You missed:
>
> -common-obj-y += scsi-disk.o emulation.o
> -common-obj-y += scsi-generic.o scsi-bus.o
> +common-obj-$(CONFIG_SCSI) += scsi-disk.o emulation.o
> +common-obj-$(CONFIG_SCSI) += scsi-generic.o scsi-bus.o
>
I didn't: :)
devices-dirs-
Patchew URL:
https://patchew.org/QEMU/20190123065618.3520-1-yang.zh...@intel.com/
Hi,
This series failed the docker-mingw@fedora 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 ===
On 31/01/19 22:48, Philippe Mathieu-Daudé wrote:
> There is something I don't understand here: Does CONFIG_XEN in
> Kconfig.host take precedence over the target configs? I'm looking at
> these configs:
>
> if supported_xen_target $target; then
> echo "CONFIG_XEN=n" >> $config_target_mak
>
On 1/25/19 11:06 AM, Paolo Bonzini wrote:
> From: Yang Zhong
>
> Use CONFIG_EDID to make edid-generate.c and edid-region.c
> configurable.
>
> Signed-off-by: Yang Zhong
> Reviewed-by: Thomas Huth
> Message-Id: <20190123065618.3520-26-yang.zh...@intel.com>
> Signed-off-by: Paolo Bonzini
Revie
Hi Paolo,
On 1/25/19 11:07 AM, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Yang Zhong
> Acked-by: Thomas Huth
> Message-Id: <20190123065618.3520-38-yang.zh...@intel.com>
> Signed-off-by: Paolo Bonzini
> ---
> default-configs/i386-softmmu.mak | 2 --
> hw/Makefile.objs
The main problem here is, that there is no prebuilt compiler packages. Thus
I have to build the toolchain from scratch. I don't know if this is OK in
the docker image. For now only binutils is built. But then, I'll have to
pass the LD and AS environment variables, too. And it won't work with the
na
The lm32 architecture doesn't need the complete compiler. In fact, only
the building of GCC is skipped to make building the docker image faster.
Signed-off-by: Michael Walle
---
tests/tcg/Makefile.include | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/tests/tc
On 1/30/19 7:01 AM, Eric Blake wrote:
> On 1/29/19 7:51 AM, Cornelia Huck wrote:
>> Given that there have been several of these cases (and that there's a
>> lot of boilerplate in general): Should we adopt SPDX license
>> identifiers for QEMU, as the Linux kernel did? They also discovered and
>> fix
Convert the existing to the new common cross build infrastructure.
Signed-off-by: Michael Walle
---
tests/tcg/lm32/Makefile| 106 -
tests/tcg/lm32/Makefile.include| 8 +++
tests/tcg/lm32/Makefile.softmmu-target | 33 ++
3 files c
Alexey Kardashevskiy writes:
> On 31/01/2019 03:30, Fabiano Rosas wrote:
>> Alexey Kardashevskiy writes:
>>
>>>
>>> but this is a register which does not have endianness, the endianness
>>> appears here because the interface between gdb and qemu is
>>> uint8_t*==bytestream but this interface sh
Patchew URL:
https://patchew.org/QEMU/1548410831-19553-1-git-send-email-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC PATCH v5 00/52] Support Kconfig in QEMU
Type: series
Message-id: 1548410831-
Unfortunately, there is no debian package for the lm32 toolchain. To
keep the build times short, only build the binutils from scratch.
Signed-off-by: Michael Walle
---
tests/docker/Makefile.include | 5 ++--
tests/docker/dockerfiles/debian-lm32-cross.docker | 31
Patchew URL:
https://patchew.org/QEMU/1548410831-19553-1-git-send-email-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1548410831-19553-1-git-send-email-pbonz...@redhat.com
Subject: [Qemu-devel] [R
Patchew URL:
https://patchew.org/QEMU/1548410831-19553-1-git-send-email-pbonz...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC PATCH v5 00/52] Support Kconfig in QEMU
Message-id: 1548410831-19553-1-git-s
On 01.02.2019 0:03, Eric Blake wrote:
On 1/31/19 2:26 PM, Julia Suvorova via Qemu-devel wrote:
The whitelist option allows to run a reduced monitor with a subset of
QMP commands. This allows the monitor to run in secure mode, which is
convenient for sending commands via the WebSocket monitor usi
On 1/25/19 11:06 AM, Paolo Bonzini wrote:
> Do not link it unconditionally into all binaries.
Nice :)
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Yang Zhong
> Reviewed-by: Thomas Huth
> Message-Id: <20190123065618.3520-3-yang.zh...@intel.com>
> Signed-off-by: Paolo Bonzini
Reviewed-by: P
On 1/25/19 11:06 AM, Paolo Bonzini wrote:
> From: Ákos Kovács
>
> Add the new configs to default-configs/mips*-sofmmu.mak.
>
> Signed-off-by: Ákos Kovács
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Yang Zhong
> Message-Id: <20190123065618.3520-8-yang.zh...@intel.com>
> Reviewed-by: Thomas
On Thu, Jan 31, 2019 at 7:57 PM Kevin Wolf wrote:
This will be very useful for new oVirt Cinder based storage. Thanks for
working on this!
I did not see any discussion about this here, but I did not follow this
list closely
lately. Do we have more info on this? a feature page describing the use
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v5 00/35] target/riscv: Convert to decodetree
Message-id: 20190122092909.53
Hi Paolo,
On 1/25/19 11:06 AM, Paolo Bonzini wrote:
> The make_device_config.sh script is replaced by minikconf, which
> is modified to support the same command line as its predecessor.
>
> The roots of the parsing are default-configs/*.mak, Kconfig.host and
> hw/Kconfig. One difference with mak
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v5 00/35] target/riscv: Convert to decodetree
Type: series
Message-id: 2019
On Thu, Jan 31, 2019 at 8:43 PM Eric Blake wrote:
...
> > @@ -450,8 +461,10 @@ Standard Cluster Descriptor:
>
> 1 - 8:Reserved (set to 0)
> >
> > 9 - 55:Bits 9-55 of host cluster offset. Must be aligned
> to a
> > -cluster boundary. If the offset i
On 1/31/19 1:51 PM, no-re...@patchew.org wrote:
Patchew URL:
https://patchew.org/QEMU/20190121170731.2500692-1-stef...@linux.ibm.com/
Seems unrelated to the series I sent...
On 1/30/19 12:59 AM, Catherine Ho wrote:
> Without this patch, gcc might up the Input/Output registers and
> cause unpredictable error.
>
> Fixes: 1ec182c33379 ("target/arm: Convert to HAVE_CMPXCHG128")
>
> Signed-off-by: Catherine Ho
Queued, thanks.
r~
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190122092909.5341-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PAT
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v5 00/35] target/riscv: Convert to decodetree
Type: series
Message-id: 2019
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v5 00/35] target/riscv: Convert to decodetree
Message-id: 20190122092909.53
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [PATCH v5 00/35] target/riscv: Convert to decodetree
Message-id: 20190122092909.53
Patchew URL:
https://patchew.org/QEMU/20190122092909.5341-1-kbast...@mail.uni-paderborn.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20190122092909.5341-1-kbast...@mail.uni-paderborn.de
Subject: [Qemu-devel] [PAT
1 - 100 of 413 matches
Mail list logo
