Laszlo Ersek writes:
> On 06/24/19 12:18, Kevin Wolf wrote:
>> Am 24.06.2019 um 10:01 hat Klaus Birkelund geschrieben:
>>> On Thu, Jun 20, 2019 at 05:37:24PM +0200, Laszlo Ersek wrote:
On 06/17/19 10:12, Klaus Birkelund wrote:
> Hi all,
>
> I'm thinking about how to support
On 6/25/2019 1:00 PM, Eduardo Habkost wrote:
Add new version of Cascadelake-Server CPU model, setting
stepping=5 and enabling the IA32_ARCH_CAPABILITIES MSR.
The new feature will introduce a new host software requirement,
breaking our CPU model runnability promises. This means we can't
enable
Patchew URL:
https://patchew.org/QEMU/20190625050008.12789-1-ehabk...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190625050008.12789-1-ehabk...@redhat.com
Type: series
Subject: [Qemu-devel] [PATCH 0/6] x86 CPU
Add new version of Cascadelake-Server CPU model, setting
stepping=5 and enabling the IA32_ARCH_CAPABILITIES MSR.
The new feature will introduce a new host software requirement,
breaking our CPU model runnability promises. This means we can't
enable the new CPU model version by default in QEMU
Base code for versioned CPU models. This will register a "-4.1"
version of all existing CPU models, and make the unversioned CPU
models be an alias for the -4.1 versions on the pc-*-4.1 machine
types.
On older machine types, the unversioned CPU models will keep the
old behavior. This way,
Document that CPU model runnability guarantees won't apply to
unversioned CPU models anymore.
Signed-off-by: Eduardo Habkost
---
Cc: libvir-l...@redhat.com
---
qemu-deprecated.texi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/qemu-deprecated.texi
The variable is completely unused, probably a leftover from
previous code clean up.
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1bad957f6e..cf03dc786e 100644
--- a/target/i386/cpu.c
+++
Management software will be expected to resolve CPU model name
aliases using the new field.
Signed-off-by: Eduardo Habkost
---
Cc: Eric Blake
Cc: Markus Armbruster
---
qapi/target.json | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/qapi/target.json
This series implements basic infrastructure for CPU model
versioning, as discussed before[1][2][3]. This will finally
allow us to update CPU models in ways that introduce new software
or hardware requirements.
My original plan was to use "query-cpu-model-expansion
mode=static" to resolve
Add a new option that can be used to disable feature flag
filtering. This will allow CPU model compatibility test cases to
work without host hardware dependencies.
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.h | 6 ++
target/i386/cpu.c | 8 ++--
2 files changed, 12
On Fri, Jun 21, 2019 at 08:31:53AM +0800, Yan Zhao wrote:
> On Thu, Jun 20, 2019 at 10:37:36PM +0800, Kirti Wankhede wrote:
> > Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
> > functions. These functions handles pre-copy and stop-and-copy phase.
> >
> > In
The double slash in path will fail the installation on MINGW/MSYS.
Fixes: a8260d387638 (ui: install logo icons to $prefix/share/icons)
Signed-off-by: Colin Xu
---
Makefile | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index
It is wrong for an entry to have parts out of scope of notifier's range.
assert this condition.
Out of scope mapping/unmapping would cause problem, as in below case:
1. initially there are two notifiers with ranges
0-0xfedf, 0xfef0-0x,
IOVAs from 0x3c00 - 0x3c1f
On Mon, Jun 24, 2019 at 06:11:11PM +0800, Auger Eric wrote:
> Hi Yan,
>
> On 6/24/19 10:39 AM, Yan Zhao wrote:
> > if an entry has parts out of scope of notifier's range, print warning
> > message.
> >
> > Out of scope mapping/unmapping would cause problem, as in below case:
> >
> > 1.
Tested-by: Yan Zhao
On Mon, Jun 24, 2019 at 05:18:11PM +0800, Peter Xu wrote:
> This is an replacement work of Yan Zhao's patch:
>
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg625340.html
>
> vtd_address_space_unmap() will do proper page mask alignment to make
> sure each IOTLB
On Mon, Jun 24, 2019 at 08:16:35AM -0700, Li Qiang wrote:
> irq_eoi is used to count the number of irq injected during eoi
> broadcast. It should be set to 0 when updating the ioapic's redirect
> table entry.
>
> Suggested-by: Peter Xu
> Signed-off-by: Li Qiang
> ---
> hw/intc/ioapic.c | 1 +
>
Patchew URL:
https://patchew.org/QEMU/cover.1561419713.git.alistair.fran...@wdc.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: cover.1561419713.git.alistair.fran...@wdc.com
Type: series
Subject: [Qemu-devel] [PATCH v2 0/4]
On Jun 25, 2019 12:44 AM, "Philippe Mathieu-Daudé" wrote:
>
> One byte is missing, use an aligned size.
>
> (qemu) info mtree
> memory-region: pci0-mem
> -fffe (prio 0, i/o): pci0-mem
> ^
>
> Signed-off-by: Philippe
On Jun 25, 2019 12:46 AM, "Philippe Mathieu-Daudé" wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
Philipoe, can you hust clarify (explain) what is the criterium when to use
log message, and when to use trace event, which are bith present in gt64xxx
implementation.
> Makefile.objs
On Jun 25, 2019 12:42 AM, "Philippe Mathieu-Daudé" wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
This patch is not only mechanical replacement of printf(), but it also
improves existing log messages, and adds some new ones as well. Reflect
that in both commit message title and body.
On Jun 25, 2019 12:29 AM, "Philippe Mathieu-Daudé" wrote:
>
> Since we'll move this code around, fix its style first:
>
> ERROR: space prohibited between function name and open parenthesis
> ERROR: line over 90 characters
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
Reviewed-by:
On Jun 25, 2019 12:38 AM, "Philippe Mathieu-Daudé" wrote:
>
> Since we'll move this code around, fix its style first:
>
> ERROR: braces {} are necessary for all arms of this statement
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
Reviewed-by: Aleksandar Markovic
> hw/mips/gt64xxx_pci.c |
On Jun 25, 2019 12:30 AM, "Philippe Mathieu-Daudé" wrote:
>
> Since we'll move this code around, fix its style first:
>
> ERROR: code indent should never use tabs
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
Reviewed-by: Aleksandar Markovic
> hw/mips/gt64xxx_pci.c | 312
On Jun 25, 2019 12:36 AM, "Philippe Mathieu-Daudé" wrote:
>
> Since commit 8c06fbdf36b checkpatch.pl enforce a new multiline
> comment syntax. Since we'll move this code around, fix its style
> first.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
Yes, I find that this a very good practice
From: Michael Clark
This patch adds support for the riscv_cpu_unassigned_access call
and will raise a load or store access fault.
Signed-off-by: Michael Clark
[Changes by AF:
- Squash two patches and rewrite commit message
- Set baddr to the access address
]
Signed-off-by: Alistair Francis
From: Michael Clark
Due to the design of the disassembler, the immediate is not
known during decoding of the opcode; so to handle compressed
encodings with reserved immediate values (non-zero), we need
to add an additional check during decompression to match
reserved encodings with zero
From: Michael Clark
The constraint for `rdinstreth` was comparing the csr number to 0xc80,
which is `cycleh` instead. Fix this.
Signed-off-by: Wladimir J. van der Laan
Signed-off-by: Michael Clark
Signed-off-by: Alistair Francis
---
disas/riscv.c | 4 ++--
1 file changed, 2 insertions(+), 2
From: Dayeol Lee
A wrong address is passed to `pmp_is_in_range` while checking if a
memory access is within a PMP range.
Since the ending address of the pmp range (i.e., pmp_state.addr[i].ea)
is set to the last address in the range (i.e., pmp base + pmp size - 1),
memory accesses containg the
This should be the last series bringing the patches from the RISC-V fork
into mainline QEMU.
v2:
- Add Wladimir's SOB line, after talking to them
- Allow c.andi to have a 0 immediate
Dayeol Lee (1):
target/riscv: Fix PMP range boundary address bug
Michael Clark (3):
disas/riscv:
On Mon, 2019-06-24 at 16:24 -0700, Alistair Francis wrote:
> On Mon, Jun 24, 2019 at 3:57 PM Atish Patra
> wrote:
> > Currently, there is no cpu topology defined in RISC-V.
> > Define a device tree node that clearly describes the
> > entire topology. This saves the trouble of scanning individual
Currently, there is no cpu topology defined in RISC-V.
Define a device tree node that clearly describes the
entire topology. This saves the trouble of scanning individual
cache to figure out the topology.
Here is the linux kernel patch series that enables topology
for RISC-V.
On Mon, Jun 24, 2019 at 3:57 PM Atish Patra wrote:
>
> Currently, there is no cpu topology defined in RISC-V.
> Define a device tree node that clearly describes the
> entire topology. This saves the trouble of scanning individual
> cache to figure out the topology.
>
> Here is the linux kernel
On Mon, Jun 24, 2019 at 2:31 AM Palmer Dabbelt wrote:
>
> On Mon, 17 Jun 2019 18:31:25 PDT (-0700), Alistair Francis wrote:
> > For completeness let's add Zifencei and Zicsr as command line options,
> > even though they can't be disabled at the moment.
> >
> > Signed-off-by: Alistair Francis
> >
When vCPU is in VMX operation and enters SMM mode,
it temporarily exits VMX operation but KVM maintained nested-state
still stores the VMXON region physical address, i.e. even when the
vCPU is in SMM mode then (nested_state->hdr.vmx.vmxon_pa != -1ull).
Therefore, there is no need to explicitly
Apparently my previous message didn't make it out onto the list (sorry
about all these email glitches!). I've included the message again below.
Hopefully either a patch like this one or something simpler that just hard
codes mcounteren.TM to zero (so QEMU is at least conformant) can be merged
in
Currently, there is no cpu topology defined in RISC-V.
Define a device tree node that clearly describes the
entire topology. This saves the trouble of scanning individual
cache to figure out the topology.
Here is the linux kernel patch series that enables topology
for RISC-V.
On 06/24/2019 03:03 PM, Eduardo Habkost wrote:
Any objections to this? I'm planning to merge it this week.
IMHO, 1+. So I don't have objections.
- Wainer
On Sat, Jun 08, 2019 at 08:34:46PM -0300, Eduardo Habkost wrote:
Changes v1 -> v2:
* I've decided to get rid of the status-message
Signed-off-by: Philippe Mathieu-Daudé
---
Makefile.objs | 1 +
hw/mips/gt64xxx_pci.c | 29 ++---
hw/mips/trace-events | 4
3 files changed, 15 insertions(+), 19 deletions(-)
create mode 100644 hw/mips/trace-events
diff --git a/Makefile.objs
One byte is missing, use an aligned size.
(qemu) info mtree
memory-region: pci0-mem
-fffe (prio 0, i/o): pci0-mem
^
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/gt64xxx_pci.c | 3 ++-
1 file changed, 2
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/gt64xxx_pci.c | 48 +--
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c
index 0b9fb02475..f44326f14f 100644
--- a/hw/mips/gt64xxx_pci.c
+++
Since we'll move this code around, fix its style first:
ERROR: braces {} are necessary for all arms of this statement
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/gt64xxx_pci.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git
The SysAd bus is split in various address spaces.
Declare the different regions separately, this helps a lot
while tracing different access while debugging.
We also add the PCI1 ranges.
See 'GT-64120A System Controller' datasheet Rev, 1.1,
"Table 15: CPU and Device Decoder Default Address
Since commit 8c06fbdf36b checkpatch.pl enforce a new multiline
comment syntax. Since we'll move this code around, fix its style
first.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/gt64xxx_pci.c | 64 +++
1 file changed, 35 insertions(+), 29
The GT-64120 is a north-bridge, and it is not MIPS specific.
Move it with the other north-bridge devices.
We move this device in the common-obj, and compile it once for
the 4 different MIPS targets.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/{mips/gt64xxx_pci.c => pci-host/gt64120.c} | 0
This device does not have to be TARGET-dependent.
Add a 'cpu_big_endian' property which sets the byte-swapping
options if required.
Signed-off-by: Philippe Mathieu-Daudé
---
I might change my mind and name it 'little_endian' to be closer
to the datasheet.
---
include/hw/mips/mips.h | 2 +-
Hi,
This series clean the gt64120 device.
It is no more target-dependent, and tracing is improved.
Regards,
Phil.
Based-on: 20190624220056.25861-1-f4...@amsat.org
https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg05304.html
Philippe Mathieu-Daudé (10):
hw/mips/gt64xxx_pci: Fix
Since we'll move this code around, fix its style first:
ERROR: code indent should never use tabs
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/gt64xxx_pci.c | 312 +-
1 file changed, 156 insertions(+), 156 deletions(-)
diff --git
Since we'll move this code around, fix its style first:
ERROR: space prohibited between function name and open parenthesis
ERROR: line over 90 characters
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/gt64xxx_pci.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff
If the user hasn't specified a firmware to load (with -bios) or
specified no bios (with -bios none) then load OpenSBI by default. This
allows users to boot a RISC-V kernel with just -kernel.
Signed-off-by: Alistair Francis
---
hw/riscv/boot.c | 49
Split the common RISC-V boot functions into a seperate file. This allows
us to share the common code.
Signed-off-by: Alistair Francis
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
hw/riscv/Makefile.objs | 1 +
hw/riscv/boot.c | 69 +
Add support for loading a firmware file for the virt machine and the
SiFive U. This can be run with the following command:
qemu-system-riscv64 -machine virt -bios fw_jump.bin -kernel vmlinux
Signed-off-by: Alistair Francis
---
hw/riscv/boot.c | 26 ++
Add OpenSBI version 0.3 as a git submodule and as a prebult binary.
Signed-off-by: Alistair Francis
---
.gitmodules | 3 ++
Makefile | 5 +-
pc-bios/opensbi-riscv32-virt-fw_jump.bin | Bin 0 -> 28848 bytes
This series consolidates the current RISC-V kernel loading
impelementation while also adding support for the -bios option and more
advanced kernel image types.
After consolidating the kernel loading we can extend the boot loader to
support a -bios option. We can also extend the kernel loading
Extend the RISC-V kernel loader to support Image and uImage files.
A Linux kernel can now be booted with:
qemu-system-riscv64 -machine virt -bios fw_jump.bin -kernel Image
Signed-off-by: Alistair Francis
---
hw/riscv/boot.c | 18 ++
1 file changed, 14 insertions(+), 4
If few commits empty_slot_init() will take 'name' as argument.
Meanwhile, initialize it as 'empty-slot'.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/misc/empty_slot.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/misc/empty_slot.c b/hw/misc/empty_slot.c
index
These devices are not slots on a bus, but real devices that
we do not implement.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/sparc/sun4m.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
index cc85598d5b..0df5a8edfc 100644
---
The EmptySlot and UnimplementedDevice are very similar, the only
difference is how they log guest accesses.
Maintain them altogether.
Signed-off-by: Philippe Mathieu-Daudé
---
Peter, are you OK with that? Do you prefer 2 distinct sections?
MAINTAINERS | 4 +++-
1 file changed, 3 insertions(+),
Use the slot name to have more meaningful tracing logs.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/misc/empty_slot.h | 3 ++-
hw/mips/mips_malta.c | 2 +-
hw/misc/empty_slot.c | 6 --
hw/sparc/sun4m.c | 9 ++---
4 files changed, 13 insertions(+), 7
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/empty_slot.h| 7 ---
include/hw/misc/empty_slot.h | 32
hw/mips/mips_malta.c | 2 +-
hw/{core => misc}/empty_slot.c | 2 +-
hw/sparc/sun4m.c | 2 +-
Now than the empty_slot device can be overlapped, use it to cover
the maximum memory range.
We can simplify now the main RAM is created.
The TYPE_SUN4M_MEMORY is not migratable, simply remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/sparc/sun4m.c | 85
Hi, this is another clean-up series, paving the road for a later
series touching the GT64120 north bridge.
It makes the EMPTY_SLOT more in shape with the UNIMPLEMENTED_DEVICE,
and slighly more powerful (allowing overlapping, trace events).
Previous discussions with Artyom and Peter:
-
The 'empty_slot' models a ChipEnable (or ChipSelect) MMIO device
pluggable on a bus.
The bus allow such slots to be not connected ('empty), thus no
bus errors are generated when this range is accessed.
The device is mapped at priority -1 to allow other devices
to be mapped on top of it.
Add a qdev 'size' property, check the size is not zero in the
realize() function, simplify the empty_slot_init() logic.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/misc/empty_slot.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git
Signed-off-by: Philippe Mathieu-Daudé
---
hw/misc/empty_slot.c | 19 ---
hw/misc/trace-events | 4
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/hw/misc/empty_slot.c b/hw/misc/empty_slot.c
index c32241a9e5..b81064 100644
--- a/hw/misc/empty_slot.c
+++
** 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.
https://bugs.launchpad.net/bugs/1831545
Title:
"accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86
Le 19/06/2019 à 16:17, Aleksandar Markovic a écrit :
> From: Neng Chen
>
> Add support for the option IPV6__MEMBERSHIP of the syscall
> setsockopt(). This option controls membership in multicast groups.
> Argument is a pointer to a struct ipv6_mreq.
>
> The glibc header defines the ipv6_mreq
Le 19/06/2019 à 16:17, Aleksandar Markovic a écrit :
> From: Yunqiang Su
>
> Add support for options SOL_ALG of the syscall setsockopt(). This
> option is used in relation to Linux kernel Crypto API, and allows
> a user to set additional information for the cipher operation via
> syscall
Le 29/05/2019 à 10:48, Laurent Vivier a écrit :
> When we have updated kernel headers to 5.2-rc1 we have introduced
> new syscall numbers that can be not supported by older kernels
> and fail with ENOSYS while the guest emulation succeeded before
> because the syscalls were emulated with ipc().
>
Le 19/06/2019 à 00:32, Jim Wilson a écrit :
> 32-bit RISC-V uses _llseek instead of lseek as syscall number 62.
> Update syscall list from open-embedded build, primarily because
> 32-bit RISC-V requires statx support.
>
> Tested with cross gcc testsuite runs for rv32 and rv64, with the
> pending
On 06/24/19 12:18, Kevin Wolf wrote:
> Am 24.06.2019 um 10:01 hat Klaus Birkelund geschrieben:
>> On Thu, Jun 20, 2019 at 05:37:24PM +0200, Laszlo Ersek wrote:
>>> On 06/17/19 10:12, Klaus Birkelund wrote:
Hi all,
I'm thinking about how to support multiple namespaces in the NVMe
Hi Alex,
Thanks for your reply.
For the different frequencies, please see below code in armv7m_systick.c and
mps2.c first, the s->reload will be set by the guest os code according to the
CPU's frequency which will be SYSCLK_FRQ, and s->tick will be set as "s->tick
+= (s->reload + 1) *
> On Jun 24, 2019, at 12:05, Philippe Mathieu-Daudé wrote:
>
>> On 6/22/19 2:25 PM, Philippe Mathieu-Daudé wrote:
>> Hi Stephen,
>>
>> This series haven't fall through the cracks, however it is taking me
>> longer than expected to review it.
>>
>>> On 4/26/19 6:26 PM, Stephen Checkoway
Ping?
Le 09/06/2019 à 16:35, Laurent Vivier a écrit :
> QEMU_PPC_FEATURE2_VEC_CRYPTO enables the use
> of VSX instructions in libcrypto that are accelerated
> by the TCG vector instructions now.
>
> QEMU_PPC_FEATURE2_DARN allows to use the new builtin
> qemu_guest_getrandom() function.
>
>
On Mon, Jun 24, 2019 at 2:31 AM Palmer Dabbelt wrote:
>
> On Mon, 17 Jun 2019 18:31:08 PDT (-0700), Alistair Francis wrote:
> > Add a comment for the new mcountinhibit which conflicts with the
> > CSR_MUCOUNTEREN from version 1.09.1. This can be updated when we remove
> > 1.09.1.
> >
> >
On Mon, Jun 24, 2019 at 2:33 AM Palmer Dabbelt wrote:
>
> On Mon, 17 Jun 2019 18:31:00 PDT (-0700), Alistair Francis wrote:
> > Based-on:
> >
> > Now that the RISC-V spec has started to be ratified let's update our
> > QEMU implementation. There are a few things going on here:
> > - Add priv
On 24.06.19 19:39, Max Reitz wrote:
> By applying qdict_flatten(), the flat-confused input visitor, and the
> output visitor, we can at least try to bring bs->full_open_options into
> accordance with the QAPI schema. This may not always work (there are
> some options left that have not been
Hi,
Jason, Can I have an Acked-by from you (as network devices maintainer)?
Thanks,
Laurent
Le 20/06/2019 à 00:19, Laurent Vivier a écrit :
> This is needed by Quadra 800, this card can run on little-endian
> or big-endian bus.
>
> Signed-off-by: Laurent Vivier
> Tested-by: Hervé Poussineau
On 24.06.19 21:00, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20190624173935.25747-1-mre...@redhat.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
bug fixed in current git (commit
474f3938d79ab36b9231c9ad3b5a9314c2aeacde). Thanks, Alex!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1831545
Title:
"accel/tcg: demacro cputlb" break
Hi,
Paolo, can I have an "Acked-by" from you (as SCSI maintainer)?
The new PDMA states are not migrated, but as this is only used by q800
emulation, and q800 doesn't support migration too, I think it could be
added later.
Thanks,
Laurent
Le 20/06/2019 à 00:19, Laurent Vivier a écrit :
> There
Hi,
Marc-André, can I have an Acked-by from you (as character devices
maintainer)?
Thanks,
Laurent
Le 20/06/2019 à 00:19, Laurent Vivier a écrit :
> On Sparc and PowerMac, the bit 0 of the address
> selects the register type (control or data) and
> bit 1 selects the channel (B or A).
>
> On
On Mon, Jun 24, 2019 at 09:39:13PM +0200, Max Reitz wrote:
> find_next_bit() takes a pointer of type "const unsigned long *", but the
> first argument passed here is a "uint64_t *". These types are
> incompatible when compiling qemu with -m32.
>
> Just use ctz64() instead.
>
> Fixes:
On Mon, Jun 24, 2019 at 09:30:26PM +0200, Max Reitz wrote:
> On 24.06.19 21:26, Max Reitz wrote:
> > On 24.06.19 21:21, Eduardo Habkost wrote:
> >> On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote:
> >>> find_next_bit() takes a pointer of type "const unsigned long *", but the
> >>> first
find_next_bit() takes a pointer of type "const unsigned long *", but the
first argument passed here is a "uint64_t *". These types are
incompatible when compiling qemu with -m32.
Just use ctz64() instead.
Fixes: c686193072a47032d83cb4e131dc49ae30f9e5d
Signed-off-by: Max Reitz
---
On 24.06.19 21:26, Max Reitz wrote:
> On 24.06.19 21:21, Eduardo Habkost wrote:
>> On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote:
>>> find_next_bit() takes a pointer of type "const unsigned long *", but the
>>> first argument passed here is a "uint64_t *". These types are
>>>
On 24.06.19 21:21, Eduardo Habkost wrote:
> On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote:
>> find_next_bit() takes a pointer of type "const unsigned long *", but the
>> first argument passed here is a "uint64_t *". These types are
>> incompatible when compiling qemu with -m32.
>>
>>
On Mon, Jun 24, 2019 at 09:02:14PM +0200, Max Reitz wrote:
> find_next_bit() takes a pointer of type "const unsigned long *", but the
> first argument passed here is a "uint64_t *". These types are
> incompatible when compiling qemu with -m32.
>
> Just cast it to "const void *", find_next_bit()
find_next_bit() takes a pointer of type "const unsigned long *", but the
first argument passed here is a "uint64_t *". These types are
incompatible when compiling qemu with -m32.
Just cast it to "const void *", find_next_bit() works fine with any type
on little-endian hosts (which x86 is).
On 6/22/19 2:25 PM, Philippe Mathieu-Daudé wrote:
> Hi Stephen,
>
> This series haven't fall through the cracks, however it is taking me
> longer than expected to review it.
>
> On 4/26/19 6:26 PM, Stephen Checkoway wrote:
>> It's common for multiple narrow flash chips to be hooked up in
Patchew URL: https://patchew.org/QEMU/20190624173935.25747-1-mre...@redhat.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
make
On 24.06.19 21:04, Max Reitz wrote:
> On 24.06.19 20:35, no-re...@patchew.org wrote:
>> Patchew URL:
>> https://patchew.org/QEMU/20190624173935.25747-1-mre...@redhat.com/
>>
>>
>>
>> Hi,
>>
>> This series seems to have some coding style problems. See output below for
>> more information:
>>
>>
On 24.06.19 20:35, no-re...@patchew.org wrote:
> Patchew URL:
> https://patchew.org/QEMU/20190624173935.25747-1-mre...@redhat.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Message-id:
On Tue, 25 Jun 2019 00:22:16 +0530
Kirti Wankhede wrote:
> On 6/24/2019 8:55 PM, Alex Williamson wrote:
> > On Mon, 24 Jun 2019 20:30:08 +0530
> > Kirti Wankhede wrote:
> >
> >> On 6/22/2019 3:31 AM, Alex Williamson wrote:
> >>> On Sat, 22 Jun 2019 02:00:08 +0530
> >>> Kirti Wankhede
* Kirti Wankhede (kwankh...@nvidia.com) wrote:
>
>
> On 6/21/2019 2:16 PM, Yan Zhao wrote:
> > On Fri, Jun 21, 2019 at 04:02:50PM +0800, Kirti Wankhede wrote:
> >>
> >>
> >> On 6/21/2019 6:54 AM, Yan Zhao wrote:
> >>> On Fri, Jun 21, 2019 at 08:25:18AM +0800, Yan Zhao wrote:
> On Thu, Jun
On 6/24/2019 8:55 PM, Alex Williamson wrote:
> On Mon, 24 Jun 2019 20:30:08 +0530
> Kirti Wankhede wrote:
>
>> On 6/22/2019 3:31 AM, Alex Williamson wrote:
>>> On Sat, 22 Jun 2019 02:00:08 +0530
>>> Kirti Wankhede wrote:
On 6/22/2019 1:30 AM, Alex Williamson wrote:
> On Sat, 22
Patchew URL: https://patchew.org/QEMU/20190624173935.25747-1-mre...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20190624173935.25747-1-mre...@redhat.com
Type: series
Subject: [Qemu-devel] [PATCH v4 00/14] block: Try
On 19-06-17 16:52:44, Richard Henderson wrote:
> On 6/16/19 12:19 PM, Joel Sing wrote:
> > +/*
> > + * Clear the load reservation, since an SC must fail if there is
> > + * an SC to any address, in between an LR and SC pair.
> > + */
> > +tcg_gen_movi_tl(load_res, 0);
> > +
> >
Hi,
I have seen the following problem several times recently. This is with qemu-4.0.
qemu-system-x86_64: hw/usb/core.c:720: usb_ep_get: Assertion `dev != NULL'
failed
Backtrace gives me the following call path.
main_loop()
main_loop_wait()
glib_pollfds_poll()
aio_ctx_dispatch()
The GlobalState struct has two confusing fields:
- uint8_t runstate[100]
- RunState state
The first field saves the 'current_run_state' from vl.c file before
migrate. The second field is filled in the post load func using the
'runstate' value. So, this commit renames the 'runstate' to
Any objections to this? I'm planning to merge it this week.
On Sat, Jun 08, 2019 at 08:34:46PM -0300, Eduardo Habkost wrote:
> Changes v1 -> v2:
> * I've decided to get rid of the status-message and
> suggested-alternative fields, to avoid more bikeshedding.
>
> This series adds machine type
1 - 100 of 306 matches
Mail list logo
