CC: qemu-triv...@nongnu.org
Signed-off-by: Li Qiang
---
hw/vfio/platform.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index e59a0234dd..d52d6552e0 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -72,7 +72,7 @@ static
CC: qemu-triv...@nongnu.org
Signed-off-by: Li Qiang
---
hw/vfio/pci.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 8cecb53d5c..08729e5875 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -40,6 +40,8 @@
#define TYPE_VFIO_PCI "vfio-
CC: qemu-triv...@nongnu.org
Signed-off-by: Li Qiang
---
hw/pci/msix.c | 2 --
hw/vfio/pci.c | 2 --
include/hw/pci/msix.h | 2 ++
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/pci/msix.c b/hw/pci/msix.c
index 4e336416a7..d39dcf32e8 100644
--- a/hw/pci/msix.c
++
As the vmstate structure names aren't related with
the QOM type names.
CC: qemu-triv...@nongnu.org
Signed-off-by: Li Qiang
---
hw/vfio/amd-xgbe.c | 2 +-
hw/vfio/ap.c| 2 +-
hw/vfio/calxeda-xgmac.c | 2 +-
hw/vfio/ccw.c | 2 +-
hw/vfio/platform.c | 2 +-
5 files c
On 5/17/2019 12:24 AM, Klaus Birkelund wrote:
On Fri, May 17, 2019 at 07:35:04AM +0200, Klaus Birkelund wrote:
Hi Kenneth,
On Thu, May 16, 2019 at 05:24:47PM -0600, Heitke, Kenneth wrote:
Hi Klaus, thank you for you review. I have one comment inline
On 5/14/2019 12:02 AM, Klaus Birkelund w
On 5/17/19 11:21 AM, Vladimir Sementsov-Ogievskiy wrote:
> This test shows that external snapshots and incremental backups are
> friends.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/254 | 52 ++
> tests/qemu-iotests/254.ou
On 5/16/19 10:35 PM, Pankaj Gupta wrote:
> Can I take it your reviewed/acked-by? or tested-by tag? for the virtio patch
> :)I don't feel that I have enough expertise to give the reviewed-by tag, but
> you can
take my acked-by + tested-by.
Acked-by: Jakub Staron
Tested-by: Jakub Staron
No kern
On 5/17/19 11:21 AM, Vladimir Sementsov-Ogievskiy wrote:
> Add new optional parameter making possible to merge bitmaps from
> different nodes. It is needed to maintain external snapshots during
> incremental backup chain history.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> qapi/bl
From: Richard Henderson
The state expected for a given test must be specifically requested
with the --xfeatures=mask command-line argument. This is recorded
with the saved state so that it is obvious if the apprentice is given
a different argument. Any features beyond what are present on the
ru
On 5/17/19 4:05 AM, Denis Plotnikov wrote:
>
>
> On 17.05.2019 2:25, John Snow wrote:
>>
>>
>> On 5/16/19 9:48 AM, Denis Plotnikov wrote:
>>> The patch adds some preparation parts for incompatible compression type
>>> feature into QCOW2 header that indicates that *all* compressed clusters
>>>
Have the --xfeature option accept "sse", "avx" and "avx512" in
addition to a plain numerical value, purely for users' convenience.
Suggested-by: Richard Henderson
Signed-off-by: Jan Bobek
---
risu_reginfo_i386.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/ris
Now that i386 and x86_64 architectures are supported by RISU, we want
to detect them and build RISU for them automatically.
Suggested-by: Richard Henderson
Signed-off-by: Jan Bobek
---
configure | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
The original code used "magic numbers", which made it unclear in
some places. Include a reference to the Intel manual where the
constants' meaning is discussed.
Signed-off-by: Jan Bobek
---
risu_reginfo_i386.c | 48 +++--
1 file changed, 33 insertions(+),
CPU-specific code in risu_reginfo_* is expected to define and export
the following symbols:
- arch_long_opts, arch_extra_help, process_arch_opt
- reginfo_size
- reginfo_init
- reginfo_is_eq
- reginfo_dump, reginfo_dump_mismatch
Make risu_reginfo_i386.c implement this interface; and while we're at
This allows us to drop dependency on NASM and build the test image
with GCC only. Adds support for x86_64, too.
Suggested-by: Richard Henderson
Signed-off-by: Jan Bobek
---
Makefile| 3 +++
test_i386.S | 41 +
test_i386.s | 27 ---
In order to build risu successfully for i386, we need files
risu_reginfo_i386.{h,c}; this patch adds the latter by extracting the
relevant code from risu_i386.c.
This patch is pure code motion; no functional changes were made.
Reviewed-by: Alex Bennée
Signed-off-by: Jan Bobek
---
risu_i386.c
The code being removed is a remnant of the past implementation; it has
since been replaced by its more powerful, architecture-independent
counterpart in reginfo.c.
Reviewed-by: Alex Bennée
Signed-off-by: Jan Bobek
---
risu_i386.c | 58 -
1 fil
In order to build risu successfully for i386, we need files
risu_reginfo_i386.{h,c}; this patch adds the former by extracting the
relevant code from risu_i386.c.
This patch is pure code motion; no functional changes were made.
Reviewed-by: Alex Bennée
Signed-off-by: Jan Bobek
---
risu_reginfo_
risu_i386.c is expected to implement the following functions:
- advance_pc
- get_reginfo_paramreg, set_ucontext_paramreg
- get_risuop
- get_pc
This patch adds the necessary code. We use EAX as the parameter
register and opcode "UD1 %xxx,%eax" for triggering RISU actions.
Suggested-by: Richard He
This patch series adds support for i386 and x86_64 architectures to
RISU. Notably, vector registers (SSE, AVX, AVX-512) are supported for
verification of the apprentice. This is V2 of the series posted in
[1].
I decided not to drop the register definitions from the second patch
as suggested by Al
At least GCC defines the symbol "i386" to 1 to signal the target
platform. We need to use "i386" as an undefined symbol in order to
correctly include risu_reginfo_i386.h from risu.h. Add an -U option to
the build command to make sure the symbol remains undefined.
Suggested-by: Richard Henderson
S
On Fri, May 17, 2019 at 3:25 PM Jonathan Behrens wrote:
>
> QEMU does not have any default firmware for RISC-V. However, it isn't possible
> to run a normal kernel binary without firmware. Thus it has previously been
> necessary to compile the two together into a single binary to pass with the
> -
There are two components of this:
* The reset vector now uses the ELF entry point instead of the DRAM base
address.
* Initrd now uses the DRAM base address to figure out the half way point of
RAM. This is more in line with the comment in load_initrd, but an alternative
strategy would be to s
QEMU does not have any default firmware for RISC-V. However, it isn't possible
to run a normal kernel binary without firmware. Thus it has previously been
necessary to compile the two together into a single binary to pass with the
-kernel flag. This patch allows passing separate firmware and kernel
Jonathan Behrens (2):
target/riscv: virt machine shouldn't assume ELF entry is DRAM base
target/riscv: Add support for -bios "firmware_filename" flag
hw/riscv/virt.c | 93 -
1 file changed, 69 insertions(+), 24 deletions(-)
--
2.20.1
On Tue, Apr 9, 2019 at 6:12 PM Marc-André Lureau
wrote:
>
> Hi,
>
> HMP and QMP commands are handled synchronously in qemu today. But
> there are benefits allowing the command handler to re-enter the main
> loop if the command cannot be handled synchronously, or if it is
> long-lasting. Some bugs
iconv is only used with if curses is enabled, there's no need to do any
configure checking for iconv, if curses is disabled. Also, ignore
--enable-iconv if curses is already disabled.
Signed-off-by: Kumar Gala
---
configure | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --
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 immediate
From: Michael Clark
The constraint for `rdinstreth` was comparing the csr number to 0xc80,
which is `cycleh` instead. Fix this.
Author: Wladimir J. van der Laan
Signed-off-by: Michael Clark
Signed-off-by: Alistair Francis
---
disas/riscv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
This should be the last series bringing the patches from the RISC-V fork
into mainline QEMU.
Dayeol Lee (1):
target/riscv: Fix PMP range boundary address bug
Michael Clark (3):
disas/riscv: Disassemble reserved compressed encodings as illegal
disas/riscv: Fix `rdinstreth` constraint
targe
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 las
On Fri, 2019-05-17 at 08:51 -0700, Bin Meng wrote:
> At present the PLIC is instantiated to support only one hart, while
> the machine allows at most 4 harts to be created. When more than 1
> hart is configured, PLIC needs to instantiated to support multicore,
> otherwise an SMP OS does not work.
>
On Fri, 2019-05-17 at 08:51 -0700, Bin Meng wrote:
> At present the cpu, plic and ethclk nodes' phandles are hard-coded
> to 1/2/3 in DT. If we configure more than 1 cpu for the machine,
> all cpu nodes' phandles conflict with each other as they are all 1.
> Fix it by removing the hardcode.
>
> Si
** Tags added: ppc64
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829576
Title:
QEMU-SYSTEM-PPC64 Regression QEMU-4.0.0
Status in QEMU:
New
Bug description:
I have been using QEMU-SYSTEM-PP
** Summary changed:
- PPC64 Regression QEMU-4.0.0
+ QEMU-SYSTEM-PPC64 Regression QEMU-4.0.0
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1829576
Title:
QEMU-SYSTEM-PPC64 Regression QEMU-4.0.0
St
Public bug reported:
I have been using QEMU-SYSTEM-PPC64 v3.1.0 to run CentOS7 PPC emulated
system. It stopped working when I upgraded to QEMU-4.0.0 . I downgraded
back to QEMU-3.1.0 and it started working again. The problem is that my
CentOS7 image will not boot up udner QEMU-4.0.0, but works fin
On Freitag, 17. Mai 2019 16:47:46 CEST Greg Kurz wrote:
> Potentially yes if another approach is satisfying enough, as I wouldn't
> want to over-engineer too much around this 9p imposed limitation. The
> right thing to do would be to come up with a new version of the protocol
> with variable sized
On Fri, May 17, 2019 at 04:06:20PM -0400, tedheadster wrote:
> On Fri, May 17, 2019 at 2:15 PM Eduardo Habkost wrote:
> > Are you running the same kernel version on all VMs?
> > X86_FEATURE_CPUID was added in Linux v4.11.
> >
>
> Eduardo,
> I am running a 4.9.162 virtual machine (very intention
On 5/17/19 12:13 PM, Eduardo Habkost wrote:
> hppa_cpu_list() is dead code and is never called. Delete it.
>
> Cc: Richard Henderson
> Reviewed-by: Igor Mammedov
> Tested-by: Philippe Mathieu-Daudé
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Eduardo Habkost
> ---
> Changes v1 -> v
On Fri, May 17, 2019 at 2:15 PM Eduardo Habkost wrote:
> Are you running the same kernel version on all VMs?
> X86_FEATURE_CPUID was added in Linux v4.11.
>
Eduardo,
I am running a 4.9.162 virtual machine (very intentionally, the
drivers I need got broken in 4.11) inside of a 5.1.2 host.
X86_F
hppa_cpu_list() is dead code and is never called. Delete it.
Cc: Richard Henderson
Reviewed-by: Igor Mammedov
Tested-by: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Eduardo Habkost
---
Changes v1 -> v2:
* Delete prototype at target/hppa/cpu.h as well
(Philippe
If CONFIG_PLUGINS is enabled then lets enable testing for all our TCG
targets. This is a simple smoke test that ensure we don't crash or
otherwise barf out by running each plugin against each test.
There is a minor knock on effect for additional runners which need
specialised QEMU_OPTS which will
Hi,
Sorry for taking so long to look at this more closely:
On Fri, Feb 15, 2019 at 10:32:38AM +, Daniel P. Berrangé wrote:
> A number of virtio devices (gpu, crypto, mouse, keyboard, tablet) only
> support the virtio-1 (aka modern) mode. Currently if the user launches
> QEMU, setting those de
On 5/17/19 7:18 AM, Max Reitz wrote:
> On 10.05.19 21:03, John Snow wrote:
>> Signed-off-by: John Snow
>> ---
>> tests/qemu-iotests/250 | 129 +
>> tests/qemu-iotests/250.out | 119 ++
>> tests/qemu-iotests/group | 1 +
On 5/15/19 1:31 PM, David Hildenbrand wrote:> +const bool equal =
extract32(c, BITS - 1, 1);> +const bool lower = extract32(c, BITS - 2, 1);>
+const bool higher = extract32(c, BITS - 3, 1);> +> +if (equal && data
== l) {> +return true;> +} else if (lower && data < l) {>
On 5/17/19 10:09 AM, Vladimir Sementsov-Ogievskiy wrote:
> 17.05.2019 16:50, Eric Blake wrote:
>> On 5/16/19 7:32 PM, John Snow wrote:
>>>
>>>
>>> On 5/16/19 8:27 AM, Vladimir Sementsov-Ogievskiy wrote:
Add new optional parameter making possible to merge bitmaps from
different nodes. I
The synth fsdriver never got used for anything else but the QTest
testcase for VirtIO 9P. And even there, QTest uses -fsdev synth and
-device virtio-9p-... directly.
Signed-off-by: Greg Kurz
Reviewed-by: Thomas Huth
---
qemu-deprecated.texi | 5 +
qemu-options.hx | 3 ++-
vl.c
Each fsdriver only supports a subset of the options that can be passed
to -fsdev. Unsupported options are simply ignored. This could cause the
user to erroneously think QEMU has a bug.
Enforce strict checking of supported options for all fsdrivers. This
shouldn't impact libvirt, since it doesn't k
This fixes several things:
- add "id" description to -virtfs documentation
- split the description into several lines in both usage and documentation
for accurateness and clarity
- add documentation and usage of the synth fsdriver
- add "throttling.*" description to -fsdev local
- add some missin
This is a leftover of the handle backend, removed in QEMU 4.0.
Signed-off-by: Greg Kurz
Reviewed-by: Thomas Huth
---
fsdev/qemu-fsdev.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/fsdev/qemu-fsdev.h b/fsdev/qemu-fsdev.h
index d9716b414492..844159d1e1ff 100644
--- a/fsdev/qemu-fsdev.h
+++
This was introduced along with -fsdev but it never got used.
Signed-off-by: Greg Kurz
Reviewed-by: Thomas Huth
---
fsdev/file-op-9p.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index 3fa062b39f1b..c757c8099f54 100644
--- a/fsdev/file-op-9p.h
+++ b
It would make sense for these types to be defined in a header file if
we had an API for fsdrivers to register themselves. In practice, we
only have three of them and it is very unlikely we add new ones since
the future of file sharing between host and guest is the upcoming
virtio-fs.
Move the type
The following changes since commit f2a930ad8c433c5583e28ec803c8ca7cb2f31ab5:
Merge remote-tracking branch 'remotes/mcayland/tags/qemu-sparc-20190517' into
staging (2019-05-17 15:46:37 +0100)
are available in the Git repository at:
https://github.com/gkurz/qemu.git tags/for-ups
Fixes: a442fe2f2b2f20e7be0934277e9400b844b11999
Cc: qemu-triv...@nongnu.org
Signed-off-by: Markus Armbruster
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index d2fc346302..cef51b2a0b 100755
--- a/configure
+++ b/configure
@@ -1745,7 +1745
On 5/15/19 1:31 PM, David Hildenbrand wrote:
> +#define DEF_VISTR(BITS)
> \
> +static int vistr##BITS(void *v1, const void *v2)
> +{
> +S390Vector tmp = {};
> +int i, cc = 3;
> +
> +for (i = 0; i < (128 / BITS); i++) {
> +c
On Thu, May 16, 2019 at 08:30:27PM -0400, tedheadster wrote:
> Paolo,
> I am running the kvm32 machine and I see a problem. Here is the
> output of /proc/cpuinfo :
>
> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
> cmov constant_tsc
>
> I see something rather important
My memory is failing here: do we still need to fix a bug where
there are unexpected writes to system_memory, or this is just a
request to include a mechanism to help us detect those cases in
the future?
On Tue, May 14, 2019 at 12:42:14PM +0300, Yury Kotov wrote:
> Ping ping
>
> 17.04.2019, 15:
On Fri, 17 May 2019 at 18:56, Eduardo Habkost wrote:
>
> On Fri, May 17, 2019 at 12:32:18PM +0200, Philippe Mathieu-Daudé wrote:
> > Hi Eduardo,
> >
> > On 5/7/19 6:34 PM, Philippe Mathieu-Daudé wrote:
> > > Hi,
> > >
> > > This series looks at Eduardo suggestions from [1]
> > > and Thomas commit
Hello,
i'm interested if it is possible to livepatch the guest kernel without
reboot.
(host kernel and microcode is patched)
Greets,
Stefan
Peter Krempa writes:
> On Wed, May 15, 2019 at 15:48:29 +0200, Markus Armbruster wrote:
>> Kevin Wolf writes:
>> > Am 18.04.2019 um 22:03 hat Markus Armbruster geschrieben:
>> >> Kevin Wolf writes:
>
> [...]
>
>> > Do you expect libvirt to check a full list of all QMP commands, types,
>> > etc.
On Fri, 17 May 2019 19:37:04 +0200
Laurent Vivier wrote:
> On 26/04/2019 08:05, David Gibson wrote:
> > From: Alexey Kardashevskiy
> >
> > NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
> > space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
> > im
On 5/15/19 1:31 PM, David Hildenbrand wrote:
> Similar to VECTOR FIND ELEMENT EQUAL, however the search also stops on
> any inequality. A match for inequality seems to have precedence over
> a match for zero, because both elements have to be zero.
>
> Signed-off-by: David Hildenbrand
> ---
> tar
On Fri, May 17, 2019 at 12:32:18PM +0200, Philippe Mathieu-Daudé wrote:
> Hi Eduardo,
>
> On 5/7/19 6:34 PM, Philippe Mathieu-Daudé wrote:
> > Hi,
> >
> > This series looks at Eduardo suggestions from [1]
> > and Thomas commit aff39be0ed97 to replace various
> > object_initialize + qdev_set_paren
Philippe Mathieu-Daudé writes:
> How do you want to proceed with all the information provided in this
> thread? I think a big table in the wiki collecting the answers is ideal.
> What do you think?
Yes, please! I haven't been able to find the time...
On 5/17/19 9:47 AM, Richard Henderson wrote:
> first_equal = n;
> first_zero = n;
> for (i = n - 1; i >= 0; --i) {
> if (data1 == data2) {
> first_equal = i;
> }
> if (data1 == 0) {
> first_zero = i;
> }
> }
>
> // As an aside
Allow VFP and neon to be disabled via a CPU property. As with
the "pmu" property, we only allow these features to be removed
from CPUs which have it by default, not added to CPUs which
don't have it.
The primary motivation here is to be able to optionally
create Cortex-M33 CPUs with no FPU, but we
The SSE-200 hardware has configurable integration settings which
determine whether its two CPUs have the FPU and DSP:
* CPU0_FPU (default 0)
* CPU0_DSP (default 0)
* CPU1_FPU (default 1)
* CPU1_DSP (default 1)
Similarly, the IoTKit has settings for its single CPU:
* CPU0_FPU (default 1)
* CP
The SSE-200 hardware has configurable integration settings which
determine whether its two CPUs have the FPU and DSP:
* CPU0_FPU (default 0)
* CPU0_DSP (default 0)
* CPU1_FPU (default 1)
* CPU1_DSP (default 1)
Similarly, the IoTKit has settings for its single CPU:
* CPU0_FPU (default 1)
* CP
Create "vfp" and "dsp" properties on the armv7m container object
which will be forwarded to its CPU object, so that SoCs can
configure whether the CPU has these features.
Signed-off-by: Peter Maydell
---
include/hw/arm/armv7m.h | 4
hw/arm/armv7m.c | 18 ++
2 files
Allow the DSP extension to be disabled via a CPU property for
M-profile CPUs. (A and R-profile CPUs don't have this extension
as a defined separate optional architecture extension, so
they don't need the property.)
Signed-off-by: Peter Maydell
---
target/arm/cpu.h | 2 ++
target/arm/cpu.c | 29
On 26/04/2019 08:05, David Gibson wrote:
> From: Alexey Kardashevskiy
>
> NVIDIA V100 GPUs have on-board RAM which is mapped into the host memory
> space and accessible as normal RAM via an NVLink bus. The VFIO-PCI driver
> implements special regions for such GPUs and emulates an NVLink bridge.
>
>
> are available in the Git repository at:
>
> git://git.kraxel.org/qemu tags/ui-20190517-pull-request
>
> for you to fetch changes up to 5fff13f245cddd3bc260dfe6ebe1b1f05b72116f:
>
> kbd-state: fix autorepeat handling (2019-05-17 13:21:40 +0200)
>
> -
* Juan Quintela (quint...@redhat.com) wrote:
> It uses num in multifd_send(). Make it coherent.
>
> Signed-off-by: Juan Quintela
Reviewed-by: Dr. David Alan Gilbert
> ---
> migration/trace-events | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/trace-events
On Fri, 17 May 2019 14:18:23 +1000
David Gibson wrote:
> spapr machine capabilities are supposed to be sent in the migration stream
> so that we can sanity check the source and destination have compatible
> configuration. Unfortunately, when we added the hpt-max-page-size
> capability, we forgot
On 5/17/2019 12:24 AM, Klaus Birkelund wrote:
On Fri, May 17, 2019 at 07:35:04AM +0200, Klaus Birkelund wrote:
Hi Kenneth,
On Thu, May 16, 2019 at 05:24:47PM -0600, Heitke, Kenneth wrote:
Hi Klaus, thank you for you review. I have one comment inline
On 5/14/2019 12:02 AM, Klaus Birkelund w
On 5/15/19 1:31 PM, David Hildenbrand wrote:
> +#define DEF_VFEE(BITS)
>
Same comment wrt inline functions applies.
Here, because there's one result, writing to byte 7, I wonder if it isn't
clearer to write the loop
first_equal = n;
* Gerd Hoffmann (kra...@redhat.com) wrote:
> Windows guests have trouble dealing with usb devices having identical
> serial numbers. So, assign unique serial numbers to usb hid devices.
> All other usb devices have this already.
>
> In the past the fixed serial number has been used to indicate wo
On Fri, 17 May 2019 at 14:29, Paolo Bonzini wrote:
>
> The following changes since commit e329ad2ab72c43b56df88b34954c2c7d839bb373:
>
> Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190513' into
> staging (2019-05-14 10:08:47 +0100)
>
> are available in the git repository at:
>
>
>
On Fri, 17 May 2019 at 17:04, Torbjorn SVENSSON
wrote:
>
> In commit 89e68b575e138d0af1435f11a8ffcd8779c237bd, the handling of
> VQADD and VQSUB was changed for Cortex-A and the new handling does
> not return properly after calling tcg_gen_gvec_4(), thus the code
> after is executed and that does
When allowing multiple down-events in a row (key autorepeat) we can't
use change_bit() any more to update the state, because autorepeat events
don't change the key state. We have to explicitly use set_bit() and
clear_bit() instead.
Cc: qemu-sta...@nongnu.org
Fixes: 35921860156e kbd-state: don't b
On 5/15/19 1:31 PM, David Hildenbrand wrote:
> +#define DEF_VFAE(BITS)
> \
> +static int vfae##BITS(void *v1, const void *v2, const void *v3, uint8_t m5)
>
First, because this *is* complicated stuff, can we find a way to use inline
fun
The following changes since commit b0f9690e78827d55a508c73432c73f057f59fd41:
Merge remote-tracking branch 'remotes/vivier/tags/m68k-staging-pull-request'
into staging (2019-05-17 10:28:23 +0100)
are available in the Git repository at:
git://git.kraxel.org/qemu tags/ui-20190517-pu
From: Samuel Thibault
E.g. BSD and Solaris even use locale-specific encoding there.
We thus have to go through the native multibyte representation and use
mbrtowc/wcrtomb to make a proper conversion.
Signed-off-by: Samuel Thibault
Tested-by: Kamil Rytarowski
Message-Id: <20190427183307.12796-
From: Samuel Thibault
The chars/attr fields are curses internals, setcchar and getcchar have
to be used instead.
Signed-off-by: Samuel Thibault
Tested-by: Kamil Rytarowski
Message-Id: <20190427183307.12796-3-samuel.thiba...@ens-lyon.org>
Signed-off-by: Gerd Hoffmann
---
ui/curses.c | 43
From: HOU Qiming
In a GVT-g setup with dmabuf and GTK GUI, the current 2D texture at
surface_gl_update_texture is not necessarily
surface->texture. Adding a glBindTexture fixes related crashes and
artifacts, and is generally more secure.
Signed-off-by: HOU Qiming
Tested-by: Marcel Apfelbaum
Sig
In commit 89e68b575e138d0af1435f11a8ffcd8779c237bd, the handling of
VQADD and VQSUB was changed for Cortex-A and the new handling does
not return properly after calling tcg_gen_gvec_4(), thus the code
after is executed and that does not know about the VQADD or VQSUB
instructions and calls abort.
D
At present the PLIC is instantiated to support only one hart, while
the machine allows at most 4 harts to be created. When more than 1
hart is configured, PLIC needs to instantiated to support multicore,
otherwise an SMP OS does not work.
Signed-off-by: Bin Meng
---
hw/riscv/sifive_u.c | 16 +++
On 5/17/19 1:00 AM, Philippe Mathieu-Daudé wrote:
>> qemu/bitops.h: Add extract8 and extract16
>> hw/registerfields.h: Add 8bit and 16bit register macros
>> Add rx-softmmu
>> MAINTAINERS: Add RX
>
> Series:
> Tested-by: Philippe Mathieu-Daudé
Thanks, missed this because patchwork doesn't
Add new optional parameter making possible to merge bitmaps from
different nodes. It is needed to maintain external snapshots during
incremental backup chain history.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
qapi/block-core.json | 22 ---
block/dirty-bitmap.c | 9 +---
On Fri, 17 May 2019 15:22:48 +0200
Thomas Huth wrote:
> On 17/05/2019 15.17, Greg Kurz wrote:
> > On Mon, 13 May 2019 12:34:10 +0200
> > Greg Kurz wrote:
> >
> >> This fixes several things:
> >> - add "id" description to -virtfs documentation
> >> - split the description into several lines in
Hi all!
We need to copy bitmaps to new top node on external snapshot, to
not break incremental backup chain.
The only thing to do is to allow block-dirty-bitmap-merge to work
with different nodes, here it is.
v2: use 'alternate' type in qapi for specifying source bitmap
instead of adding new
This test shows that external snapshots and incremental backups are
friends.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/254 | 52 ++
tests/qemu-iotests/254.out | 52 ++
tests/qemu-iotests/group
ilable in the git repository at:
>
> git://github.com/mcayland/qemu.git tags/qemu-sparc-20190517
>
> for you to fetch changes up to 918b8adeb20d9635b16ffde7a413b15f6761b7f3:
>
> MAINTAINERS: add myself for leon3 (2019-05-17 09:17:11 +0100)
>
>
In commit 23dece19da4 ('file-posix: Make auto-read-only dynamic') ,
auto-read-only=on changed its behaviour in file-posix for the 4.0
release. This change cannot be detected through the usual mechanisms
like schema introspection. Add a new feature flag to the schema to
allow libvirt to detect the p
* Greg Kurz (gr...@kaod.org) wrote:
> Signed-off-by: Greg Kurz
> ---
> migration/migration.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 609e0df5d0c0..c15e75e0eebe 100644
> --- a/migration/migration.c
> +++ b/m
10.04.2019 23:20, Max Reitz wrote:
> What bs->file and bs->backing mean depends on the node. For filter
> nodes, both signify a node that will eventually receive all R/W
> accesses. For format nodes, bs->file contains metadata and data, and
> bs->backing will not receive writes -- instead, writes
Signed-off-by: Kevin Wolf
---
tests/qapi-schema/features-bad-type.json | 3 +++
tests/qapi-schema/features-duplicate-name.json | 3 +++
tests/qapi-schema/features-missing-name.json | 3 +++
tests/qapi-schema/features-name-bad-type.json | 3 +++
tests/qapi-schema/features-no-list.json
On Fri, 17 May 2019 at 10:07, Jason Wang wrote:
>
> The following changes since commit d8276573da58e8ce78dab8c46dd660efd664bcb7:
>
> Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20190510' into
> staging (2019-05-16 13:15:08 +0100)
>
> are available in the git repository at:
>
> htt
On Fri, 17 May 2019 15:23:01 +0200
Christian Schoenebeck wrote:
> On Freitag, 17. Mai 2019 14:30:29 CEST Greg Kurz wrote:
> > Then, we come to the bulk problem: how to handle the case where we
> > have multiple devices involved in a directory we want to share ?
> > Antonios's proposal is a clever
1 - 100 of 273 matches
Mail list logo
