On 06/10/2016 01:57, Chen Gang wrote:
>
> On 10/6/16 03:38, Laurent Vivier wrote:
>> I've removed the cannot_destroy_with_object_finalize_yet field as
>> cpu_exec_init() is not called by tilegx_cpu_initfn() anymore
>> (not tested with QOM command as tilegx is only available in linux-user
>> mod
On Thu, Oct 06, 2016 at 02:38:36PM +1100, David Gibson wrote:
> On Wed, Oct 05, 2016 at 05:31:07AM -0700, Peter Maydell wrote:
> > On 4 October 2016 at 16:43, David Gibson
> > wrote:
> > > On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
> > >> The difficulty with this patch is that
Hello,
Since I upgrade my linux kernel from linux 4.8rc1 to 4.8.0, I can observe
regression with VFIO/PCI IGD Assignment .
All works very well with linux 4.8rc1 ( broadwell/skylake cpu + win10 guest
/ Linux Guest ) .
Since linux 4.8.0, Windows guest screen is a " blink pixel , multi color
blink , a
From: Prasad J Pandit
USB xHCI controller uses ring of Transfer Request Blocks(TRB)
to process USB commands. These are processed by loop in
'xhci_ring_fetch'. A guest user could make it read and process
a same TRB infinitely. Limit number of command TRBs to avoid it.
Reported-by: Li Qiang
Signe
On Wed, Oct 05, 2016 at 01:13:18PM -0700, Peter Maydell wrote:
> On 5 October 2016 at 12:38, Laurent Vivier wrote:
> > Extract the realize part to cpu_exec_realize(), update all
> > calls to cpu_exec_init() to add cpu_exec_realize() to
> > have no functionnal change.
> >
> > Put in cpu_exec_init()
On Thu, Oct 06, 2016 at 07:57:34AM +0800, Chen Gang wrote:
>
> On 10/6/16 03:38, Laurent Vivier wrote:
> > I've removed the cannot_destroy_with_object_finalize_yet field as
> > cpu_exec_init() is not called by tilegx_cpu_initfn() anymore
> > (not tested with QOM command as tilegx is only available
On Wed, Oct 05, 2016 at 09:38:39PM +0200, Laurent Vivier wrote:
> I've removed the cannot_destroy_with_object_finalize_yet field as
> cpu_exec_init() is not called by arm_cpu_initfn() anymore
I think this (and most of the similar commit messages following) needs
a slight reword. A function called
On Wed, Oct 05, 2016 at 09:33:06PM +0200, Greg Kurz wrote:
> On Wed, 5 Oct 2016 09:34:05 +0200
> Greg Kurz wrote:
> > On Wed, 5 Oct 2016 12:14:05 +1100
> > David Gibson wrote:
> > [...]
> > You convinced me. The tswaps in qtest.c are toxic and should be removed.
> >
> > Thanks for the clarificat
On Wed, Oct 05, 2016 at 05:31:07AM -0700, Peter Maydell wrote:
> On 4 October 2016 at 16:43, David Gibson wrote:
> > On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
> >> The difficulty with this patch is that it's hard to tell whether
> >> it's really required, or if this is just ad
On Wed, Oct 05, 2016 at 03:49:18PM +0200, Cédric Le Goater wrote:
> On 10/05/2016 02:31 PM, Peter Maydell wrote:
> > On 4 October 2016 at 16:43, David Gibson
> > wrote:
> >> On Tue, Oct 04, 2016 at 01:36:09PM +0100, Peter Maydell wrote:
> >>> The difficulty with this patch is that it's hard to te
On Wed, Oct 05, 2016 at 07:20:52AM -0700, Peter Maydell wrote:
> On 5 October 2016 at 07:00, Cédric Le Goater wrote:
> > On 10/05/2016 03:53 PM, Peter Maydell wrote:
> >> Which tswap? Last time I worked through the stack of
> >> what happens I thought that we had the right set of
> >> swaps in the
Hey QEMU dev group,
I'm a graduate student at Boise State University working on my thesis
involving Virtualization/Cloud Computing Security and I wanted to ask
another IN-DEPTH question I've been trying to solve. If you have some time
it would be greatly appreciated:
*[Question:]*
Can I migrate
Currently the default PCI host bridge for the 'pseries' machine type is
constructed with its IO windows in the 1TiB..(1TiB + 64GiB) range in
guest memory space. This means that if > 1TiB of guest RAM is specified,
the RAM will collide with the PCI IO windows, causing serious problems.
Problems wo
Currently, the MMIO space for accessing PCI on pseries guests begins at
1 TiB in guest address space. Each PCI host bridge (PHB) has a 64 GiB
chunk of address space in which it places its outbound PIO and 32-bit and
64-bit MMIO windows.
This scheme as several problems:
- It limits guest RAM to
The 'spapr-pci-host-bridge' represents the virtual PCI host bridge (PHB)
for a PAPR guest. Unlike on x86, it's routine on Power (both bare metal
and PAPR guests) to have numerous independent PHBs, each controlling a
separate PCI domain.
There are two ways of configuring the spapr-pci-host-bridge
The current way we organize the IO windows into PCI space for the
pseries machine type has several problems.
- It makes it difficult to create very large MMIO spaces which is
necessary for certain PCI devices with very large BARs. This
problem has been known for a while.
- More recen
On real hardware, and under pHyp, the PCI host bridges on Power machines
typically advertise two outbound MMIO windows from the guest's physical
memory space to PCI memory space:
- A 32-bit window which maps onto 2GiB..4GiB in the PCI address space
- A 64-bit window which maps onto a large regi
no fuctional changes
Signed-off-by: Li Zhijian
---
migration/savevm.c | 51 ++-
1 file changed, 34 insertions(+), 17 deletions(-)
diff --git a/migration/savevm.c b/migration/savevm.c
index 33a2911..c36a675 100644
--- a/migration/savevm.c
+++ b/mig
Introduce a new section type to help destination to detect unknown/inconsistent
devices early that let source side stop migration and keep alive.
Prevoisly, if we have a different device list between source and distination (
e.g: souce with -device virtio-blk,drive=foo and distination with
-device
On Wed, Oct 05, 2016 at 09:44:51AM +0200, Thomas Huth wrote:
> A couple of distributors are compiling their distributions
> with "-mcpu=power8" for ppc64le these days, so the user sooner
> or later runs into a crash there when not explicitely specifying
> the "-cpu POWER8" option to QEMU (which is
On Wed, Oct 05, 2016 at 03:10:53PM +0200, Laurent Vivier wrote:
>
>
> On 05/10/2016 14:52, Thomas Huth wrote:
> > SLOF is unfortunately quite slow when running with TCG, so
> > the pxe test is also performing rather slow here. By using
> > "-nodefaults" we can disable some devices (vscsi) that we
On 09/30/2016 05:58 PM, Dr. David Alan Gilbert wrote:
* Li Zhijian (lizhij...@cn.fujitsu.com) wrote:
On 09/30/2016 02:15 PM, Amit Shah wrote:
Hi,
On (Thu) 29 Sep 2016 [19:06:32], Li Zhijian wrote:
Priviously, if the source and distination have different devices, source could
goto
the sta
On 10/05/2016 09:55 PM, Laszlo Ersek wrote:
> On 10/03/16 16:01, Denis V. Lunev wrote:
>> Unfortunately, there is no public Windows API to start trimming the
>> filesystem. The only viable way here is to call 'defrag.exe /L' for
>> each volume.
>>
>> This is working since Win8 and Win2k12.
>>
>> Si
On Tue, Oct 04, 2016 at 03:51:40PM -0700, Ed Swierk wrote:
> On Thu, Sep 15, 2016 at 5:36 PM, Michael S. Tsirkin wrote:
> > On Thu, Sep 15, 2016 at 05:23:28PM -0700, Ed Swierk wrote:
> >> I'm wondering what it will take to finish up work on vmgenid.
> >>
> >> https://lists.gnu.org/archive/html/qem
Hey QEMU dev group,
I'm a graduate student at Boise State University working on my thesis
involving Virtualization/Cloud Computing Security and I wanted to ask a few
questions:
*[QUESTION#1.]* From within a guest KVM/QEMU process (qemu-system-x86_64
-enable-kvm) can the VM invoke commands on its h
On 10/6/16 03:38, Laurent Vivier wrote:
> I've removed the cannot_destroy_with_object_finalize_yet field as
> cpu_exec_init() is not called by tilegx_cpu_initfn() anymore
> (not tested with QOM command as tilegx is only available in linux-user
> mode)
>
For master branch, I can not find cpu_ex
Patch 1 fixes a warning that gcc may unnecessarily emit.
Patch 2 fixes a real bug that sometimes shows up as a segfault in test-qht.
Daniel reported it yesterday on IRC; the trick to easily trigger it is to
run on RHEL6 (or CentOS6).
It is very likely that this is the test-qht failure that Peter r
qht_lookup is meant to be called from an RCU read-critical
section. Make sure we're in such a section in test-qht
when performing lookups, despite the fact that no races
in qht can be triggered by test-qht since it is single-threaded.
Note that rcu_register_thread is already called by the
rcu_afte
Sometimes gcc doesn't pick up the fact that 'new' is properly
set if 'resize == true', which may generate an unnecessary
build warning.
Fix it by removing 'resize' and directly checking that 'new'
is non-NULL.
Signed-off-by: Emilio G. Cota
---
util/qht.c | 8 +++-
1 file changed, 3 insertio
The old map's bucket locks are being unlocked *after*
that same old map has been passed to RCU for destruction.
This is a bug that can cause a segfault, since there's
no guarantee that the deletion will be deferred (e.g.
there may be no concurrent readers).
The segfault is easily triggered in RHEL
From: KONRAD Frederic
This adds some fixed reference clock to the zynqmp platform.
They will feed the zynqmp_crf block.
Signed-off-by: KONRAD Frederic
---
hw/arm/xlnx-zynqmp.c | 42 ++
include/hw/arm/xlnx-zynqmp.h | 6 ++
2 files changed, 48
From: KONRAD Frederic
This introduce Xilinx zynqmp-crf.
It is extracted from the qemu xilinx tree
(02d2f0203dd489ed30d9c8d90c14a52c57332b25) and is used as
an example for the clock framework.
---
hw/misc/Makefile.objs | 1 +
hw/misc/xilinx_zynqmp_crf.c | 968
From: KONRAD Frederic
This is a fixed clock device.
It justs behave as an empty device with a parametrable output rate.
Signed-off-by: KONRAD Frederic
---
hw/misc/Makefile.objs | 1 +
hw/misc/fixed-clock.c | 88 +++
include/hw/misc/fixed
From: KONRAD Frederic
This adds the zynqmp_crf to the zynqmp platform.
Signed-off-by: KONRAD Frederic
---
hw/arm/xlnx-zynqmp.c | 7 +++
include/hw/arm/xlnx-zynqmp.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 0d86ba3..05c
From: KONRAD Frederic
This introduces the clock binding and the update part.
When the qemu_clk_rate_update(qemu_clk, int) function is called:
* The clock callback is called on the qemu_clk so it can change the rate.
* The qemu_clk_rate_update function is called on all the driven clock.
Signe
From: KONRAD Frederic
This adds the qemu-clock documentation.
Signed-off-by: KONRAD Frederic
---
docs/clock.txt | 109 +
1 file changed, 109 insertions(+)
create mode 100644 docs/clock.txt
diff --git a/docs/clock.txt b/docs/clock.txt
ne
From: KONRAD Frederic
This prints the clock attached to a DeviceState when using "info qtree" monitor
command.
For example:
bus: main-system-bus
type System
dev: xlnx.zynqmp_crf, id ""
gpio-out "sysbus-irq" 1
gpio-out "RST_A9" 4
qemu-clk "dbg_trace" 0.0
qemu-clk "vpll_to_lpd
From: KONRAD Frederic
This introduces a clock init array to ease the clock tree construction.
Signed-off-by: KONRAD Frederic
---
include/qemu/qemu-clock.h | 23 +++
qemu-clock.c | 17 +
2 files changed, 40 insertions(+)
diff --git a/include/qem
From: KONRAD Frederic
Hi,
This is the first version of the clock framework API it contains:
* The first 6 patches which introduce the framework.
* The 7th patch which introduces a fixed-clock model.
* The rest which gives an example how to model a PLL from the existing
zynqmp-crf extr
From: KONRAD Frederic
This introduces qemu-clk qom object.
Signed-off-by: KONRAD Frederic
---
Makefile.objs | 1 +
include/qemu/qemu-clock.h | 40 +
qemu-clock.c | 50 +++
3 files changed,
From: KONRAD Frederic
This allows to attach a clock to a DeviceState.
Contrary to gpios, the clock pins are not contained in the DeviceState but
with the child property so they can appears in the qom-tree.
Signed-off-by: KONRAD Frederic
---
include/qemu/qemu-clock.h | 24 ++
On 5 October 2016 at 14:53, Tom Hanson wrote:
> On 09/29/2016 07:24 PM, Peter Maydell wrote:
>> On 16 September 2016 at 10:34, Thomas Hanson
>> wrote:
>>> +void gen_a64_set_pc_reg(DisasContext *s, unsigned int rn)
>>
>> I think it would be better to take a TCGv_i64 here rather than
>> unsigned i
Machine specific shutdown function can be registered by
the machine specific qtest_XXX_boot() if needed.
So we will not have to test twice the architecture (on boot and on
shutdown) if the test can be run on several architectures.
Signed-off-by: Laurent Vivier
Reviewed-by: Greg Kurz
Reviewed-by
On 09/29/2016 07:24 PM, Peter Maydell wrote:
> On 16 September 2016 at 10:34, Thomas Hanson wrote:
...
>> diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
>> index f5e29d2..4d6f951 100644
...
>> @@ -176,6 +177,58 @@ void gen_a64_set_pc_im(uint64_t val)
>> tcg_gen_movi_i64(
On 10/05/2016 04:40 PM, Tomáš Golembiovský wrote:
> When --offset is set the apparent device size has to be adjusted
> accordingly. Otherwise client may request read/write beyond the file end
> which would fail.
>
> Signed-off-by: Tomáš Golembiovský
> ---
> qemu-nbd.c | 8
> 1 file chan
Signed-off-by: Laurent Vivier
Reviewed-by: Greg Kurz
Reviewed-by: David Gibson
---
tests/e1000e-test.c | 2 +-
tests/i440fx-test.c | 2 +-
tests/ide-test.c| 2 +-
tests/ivshmem-test.c| 2 +-
tests/libqos/ahci.c | 2 +-
tests/libqos/libqos-pc.c
Signed-off-by: Laurent Vivier
---
tests/Makefile.include| 8 +++-
tests/usb-hcd-uhci-test.c | 27 +++
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/tests/Makefile.include b/tests/Makefile.include
index 8b1c171..c46a32d 100644
--- a/tests/Makefile
Signed-off-by: Laurent Vivier
---
tests/Makefile.include | 1 +
tests/libqos/pci-pc.c| 22
tests/libqos/pci-spapr.c | 272 +++
tests/libqos/pci-spapr.h | 17 +++
tests/libqos/pci.c | 22 +++-
tests/libqos/rtas.c | 45
This series enables USB tests on PPC64, and for
that implements libqos SPAPR PCI support.
v6:
- Remove Cédric's patch and use memread()/memwrite()
+ cpu_to_leXX()/leXX_to_cpu()
v5:
- Add Cédric's patch providing read/write accessors
with a specific endianness, and use it
- don't duplicate usb
This patch does three things:
- It adds a list of restrictions and ToDos
- It corrects the header --- lines to match the length of the header
- It clarifies the force-raw option
Signed-off-by: Alistair Francis
---
This patch was previously called
'docs/generic-loader: Add restrictions and
When --offset is set the apparent device size has to be adjusted
accordingly. Otherwise client may request read/write beyond the file end
which would fail.
Signed-off-by: Tomáš Golembiovský
---
qemu-nbd.c | 8
1 file changed, 8 insertions(+)
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 9
On 05/10/2016 22:13, Peter Maydell wrote:
> On 5 October 2016 at 12:38, Laurent Vivier wrote:
>> Extract the realize part to cpu_exec_realize(), update all
>> calls to cpu_exec_init() to add cpu_exec_realize() to
>> have no functionnal change.
>>
>> Put in cpu_exec_init() what initializes the CP
On Wed, Oct 5, 2016 at 12:44 AM, Markus Armbruster wrote:
> Alistair Francis writes:
>
>> On Tue, Oct 4, 2016 at 12:56 AM, Markus Armbruster wrote:
>>> Alistair Francis writes:
>>>
On Thu, Sep 29, 2016 at 10:36 PM, Markus Armbruster
wrote:
> Alistair Francis writes:
>
>
On Tue, Oct 4, 2016 at 9:14 AM, Alistair Francis
wrote:
> Add a list of known restrictions and future work that will fix these
> restrictions.
>
> Signed-off-by: Alistair Francis
NACK. Sending a V3 with more fixes. The V3 is called:
'docs/generic-loader: Update the document'
Thanks,
Alista
On 05/10/2016 22:11, Peter Maydell wrote:
> On 5 October 2016 at 12:38, Laurent Vivier wrote:
>> Since commit 42ecaba ("target-i386: Call cpu_exec_init() on realize"),
>> , commit 6dd0f83 ("target-ppc: Move cpu_exec_init() call to realize
>> function"),
>> and commit c6644fc ("s390x/cpu: Get ri
On 10/05/2016 03:24 PM, Eric Blake wrote:
On 10/05/2016 01:49 PM, John Snow wrote:
Here we have an additional caller in block/replication.c and qemu-img,
so the parameters must stay. For qemu-img, nothing changes. For
replication, the block job events are added as a side effect.
Not sure if
On Wed, Oct 05, 2016 at 01:13:18PM -0700, Peter Maydell wrote:
> On 5 October 2016 at 12:38, Laurent Vivier wrote:
> > Extract the realize part to cpu_exec_realize(), update all
> > calls to cpu_exec_init() to add cpu_exec_realize() to
> > have no functionnal change.
> >
> > Put in cpu_exec_init()
On Wed, Oct 05, 2016 at 09:38:34PM +0200, Laurent Vivier wrote:
> Since commit 42ecaba ("target-i386: Call cpu_exec_init() on realize"),
> , commit 6dd0f83 ("target-ppc: Move cpu_exec_init() call to realize
> function"),
> and commit c6644fc ("s390x/cpu: Get rid of side effects when creating a
>
On 5 October 2016 at 12:38, Laurent Vivier wrote:
> Extract the realize part to cpu_exec_realize(), update all
> calls to cpu_exec_init() to add cpu_exec_realize() to
> have no functionnal change.
>
> Put in cpu_exec_init() what initializes the CPU,
> in cpu_exec_realize() what adds it to the envi
On 5 October 2016 at 12:38, Laurent Vivier wrote:
> Since commit 42ecaba ("target-i386: Call cpu_exec_init() on realize"),
> , commit 6dd0f83 ("target-ppc: Move cpu_exec_init() call to realize
> function"),
> and commit c6644fc ("s390x/cpu: Get rid of side effects when creating a
> vcpu"),
> cpu
Instead of requiring clients to actually call the query-cpu-*
commands to find out if they are implemented, remove them from
the output of "query-commands", so clients know they are not
available.
This is implemented by extending the existing hack at
qmp_unregister_commands_hack(). I wish I could
On 10/05/2016 02:49 PM, Eduardo Habkost wrote:
> Instead of requiring clients to actually call the query-cpu-*
> commands to find out if they are implemented, remove them from
> the output of "query-commands", so clients know they are not
> available.
>
> This is implemented by extending the exist
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by uc32_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"any-unicore32-cpu")
CC: Guan Xuetao
Signed-off-by: Laurent Vivier
---
target-unicore32/cpu.c | 18 +---
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by xtensa_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"dc233c-xtensa-cpu")
CC: Max Filippov
Signed-off-by: Laurent Vivier
---
target-xtensa/cpu.c | 15 +++-
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by tricore_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"tc1796-tricore-cpu")
CC: Bastian Koppelmann
Signed-off-by: Laurent Vivier
---
target-tricore/cpu.c | 15 +++
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by tilegx_cpu_initfn() anymore
(not tested with QOM command as tilegx is only available in linux-user
mode)
CC: Chen Gang
Signed-off-by: Laurent Vivier
---
target-tilegx/cpu.c | 15 +++
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by superh_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"sh7750r-superh-cpu")
CC: Aurelien Jarno
Signed-off-by: Laurent Vivier
---
target-sh4/cpu.c | 15 +++-
On 10/05/16 21:47, Denis V. Lunev wrote:
> On 10/05/2016 09:55 PM, Laszlo Ersek wrote:
>> On 10/03/16 16:01, Denis V. Lunev wrote:
>>> Unfortunately, there is no public Windows API to start trimming the
>>> filesystem. The only viable way here is to call 'defrag.exe /L' for
>>> each volume.
>>>
>>>
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by cris_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"crisv17-cris-cpu")
CC: Edgar E. Iglesias
Signed-off-by: Laurent Vivier
---
target-cris/cpu.c | 15 +++-
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by m68k_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"any-m68k-cpu")
CC: Greg Ungerer
Signed-off-by: Laurent Vivier
---
target-m68k/cpu.c | 15 +++
1 fi
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by openrisc_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"or1200-or32-cpu")
CC: Jia Liu
Signed-off-by: Laurent Vivier
---
target-openrisc/cpu.c | 15 +++
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by sparc_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"sparc-cpu")
CC: Artyom Tarasenko
Signed-off-by: Laurent Vivier
---
target-sparc/cpu.c | 18 +-
We have now the cpu_exec_realize() in realize,
so the init part must be in init.
I've removed the cannot_destroy_with_object_finalize_yet field as
it should be removed by commit c6644fc.
(tested with QOM command provided by commit 4c315c27 with
"z890.3-s390-cpu")
CC: Richard Henderson
Signed-off
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by lm32_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"lm32-full-lm32-cpu")
CC: Michael Walle
Signed-off-by: Laurent Vivier
---
target-lm32/cpu.c | 15 +++---
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by mb_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"microblaze-cpu")
CC: Edgar E. Iglesias
Signed-off-by: Laurent Vivier
---
target-microblaze/cpu.c | 14 +++---
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by moxie_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"moxie-cpu")
CC: Anthony Green
Signed-off-by: Laurent Vivier
---
target-moxie/cpu.c | 15 +++
1 fi
We have now the cpu_exec_realize() in realize,
so the init part must be in init
CC: Alexander Graf
CC: qemu-...@nongnu.org
Signed-off-by: Laurent Vivier
---
target-ppc/translate_init.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by alpha_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"pca56-alpha-cpu")
CC: Richard Henderson
Signed-off-by: Laurent Vivier
---
target-alpha/cpu.c | 15 +++
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by arm_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"arm1026-arm-cpu")
CC: Peter Maydell
CC: qemu-...@nongnu.org
Signed-off-by: Laurent Vivier
---
target-arm/cpu.c
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by mips_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"mips-cpu")
CC: Aurelien Jarno
Signed-off-by: Laurent Vivier
---
target-mips/cpu.c | 15 +++
1 file
We have now the cpu_exec_realize() in realize,
so the init part must be in init.
I've removed the cannot_destroy_with_object_finalize_yet field as
cpu_exec_init() is not called by x86_cpu_initfn() anymore
(tested with QOM command provided by commit 4c315c27 with
"athlon-x86_64-cpu")
CC: Eduardo H
Extract the realize part to cpu_exec_realize(), update all
calls to cpu_exec_init() to add cpu_exec_realize() to
have no functionnal change.
Put in cpu_exec_init() what initializes the CPU,
in cpu_exec_realize() what adds it to the environment.
CC: Paolo Bonzini
Signed-off-by: Laurent Vivier
--
Since commit 42ecaba ("target-i386: Call cpu_exec_init() on realize"),
, commit 6dd0f83 ("target-ppc: Move cpu_exec_init() call to realize function"),
and commit c6644fc ("s390x/cpu: Get rid of side effects when creating a vcpu"),
cpu_exec_init() has been moved to realize function for some architec
On Wed, 5 Oct 2016 09:34:05 +0200
Greg Kurz wrote:
> On Wed, 5 Oct 2016 12:14:05 +1100
> David Gibson wrote:
> [...]
> You convinced me. The tswaps in qtest.c are toxic and should be removed.
>
> Thanks for the clarification.
>
Rewind. Cedric and I spent the whole day thinking about that, base
On 10/05/2016 01:49 PM, John Snow wrote:
>> Here we have an additional caller in block/replication.c and qemu-img,
>> so the parameters must stay. For qemu-img, nothing changes. For
>> replication, the block job events are added as a side effect.
>>
>> Not sure if we want to emit such events for a
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 10/05/16 19:43, Dr. David Alan Gilbert wrote:
> > I guess the other thing that should be nuked is util/readline.c if we
> > can find a good, suitably licensed alternative.
>
> http://thrysoee.dk/editline/
> https://github.com/antirez/linenoise
>
>
On 10/05/2016 01:01 PM, Max Reitz wrote:
>> +static int blk_do_attach_dev(BlockBackend *blk, void *dev)
>> + */
>> +int blk_attach_dev(BlockBackend *blk, DeviceState *dev)
>> +{
>> +return blk_do_attach_dev(blk, dev);
>> +void blk_attach_dev_legacy(BlockBackend *blk, void *dev)
>> {
>>
Public bug reported:
Writes to UART 2 and 3 disappear. As a sanity check I put printf
statements in the function stm32f2xx_usart_write in
qemu/hw/char/stm32f2xx_usart.c and recompiled qemu. The result confirmed
text sent to UART1 and UART4 are sent to that function while text sent
to UART 2 and 3
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 05/10/2016 16:29, Dr. David Alan Gilbert wrote:
> > The virtio-input conversion especially is nice and simple.
> > The only weird case is virtio-gpu, and well virtio-gpu is the one that's
> > odd here (compared to the rest of virtio).
>
> Tho
On 10/03/16 16:01, Denis V. Lunev wrote:
> Unfortunately, there is no public Windows API to start trimming the
> filesystem. The only viable way here is to call 'defrag.exe /L' for
> each volume.
>
> This is working since Win8 and Win2k12.
>
> Signed-off-by: Denis V. Lunev
> Signed-off-by: Denis
On 10/05/2016 09:43 AM, Kevin Wolf wrote:
Am 01.10.2016 um 00:00 hat John Snow geschrieben:
There's no reason to leave this to blockdev; we can do it in blockjobs
directly and get rid of an extra callback for most users.
Signed-off-by: John Snow
---
blockdev.c | 37 ++---
On 10/05/16 19:43, Dr. David Alan Gilbert wrote:
> * Markus Armbruster (arm...@redhat.com) wrote:
>
> Thanks for this.
>
>> In the beginning, there was only monitor.c, and it provided what we
>> today call HMP, at just under 500 SLOC.
>>
>> Since then, most (but not all) HMP commands have moved e
On Tue, Oct 04, 2016 at 06:13:47PM +0100, Peter Maydell wrote:
> On 4 October 2016 at 18:02, Laurent Vivier wrote:
> >
> >
> > Le 04/10/2016 à 15:13, Peter Maydell a écrit :
> >> In commit 40df8c0c0722 support was added for target-specific
> >
> > I don't have commit 40df8c0c0722, I have
> > ee8e7
On Tue, Oct 04, 2016 at 02:09:33PM +0100, Peter Maydell wrote:
> Ping? It looks like patch 1/2 of this series got into the
> recent linux-user pullreq, but this one (2/2) didn't. Do
> you want a resend as a standalone patch?
No need, I've pulled it from patchwork, for some reason this didn't get t
On Tue, 04 Oct 2016 15:20:12 +0200
Markus Armbruster wrote:
> Eric Auger writes:
>
> > This series converts VFIO-PCI to realize. It also aims at improving
> > the error reporting in case of QMP hot-plug.
> >
> > Before the series, a device_add failure would have reported:
> > {"error": {"class"
On 10/04/2016 06:29 AM, Alex Bennée wrote:
Can we replace with:
linux-user: enable parallel code generation on clone
The variable parallel_cpus controls the generation of thread aware
atomic code. We only need to set it once we have cloned our first
thread. At this point any existing translatio
On 05.10.2016 11:26, Kevin Wolf wrote:
> The event currently only contains the BlockBackend name. However, with
> anonymous BlockBackends, this is always the empty string. Add the qdev
> ID (or if none was given, the QOM path) so that the user can still see
> which device caused the event.
>
> Eve
On 10/05/2016 04:17 AM, Alex Bennée wrote:
/tmp/qemu-test/src/tcg/tcg-op.c:2296:255: error:
‘gen_helper_atomic_xor_fetchl_be’ undeclared here (not in a function)
Which makes me wonder in we should be including:
#include "exec/helper-proto.h"
And if this is generating all the prototypes it sho
On 05.10.2016 11:26, Kevin Wolf wrote:
> Almost all block devices are qdevified by now. This allows us to go back
> from the BlockBackend to the DeviceState. xen_disk is the last device
> that is missing. We'll remember in the BlockBackend if a xen_disk is
> attached and can then disable any featur
On 10/04/2016 08:47 AM, Alex Bennée wrote:
+ char is_host64[sizeof(void *) >= sizeof(uint64_t) ? 1 : -1];
This breaks with --enable-werror (and my Travis images):
config-temp/qemu-conf.c: In function ‘main’:
config-temp/qemu-conf.c:12:8: error: unused variable ‘is_host64’
[-Werror=unused-va
1 - 100 of 285 matches
Mail list logo
