The sha above is the merge, thanks Luke.
The actual change by you is
commit 2a53535af471f4bee9d6cb5b363746b8d5ed21dd
Author: Luke Shumaker
Date: Thu Dec 28 13:08:13 2017 -0500
linux-user: init_guest_space: Try to make ARM space+commpage
continuous
I'll be away a week but then look at taki
On 20.03.2018 14:07, Christian Borntraeger wrote:
> Since commit 46a99c9f73c7 ("s390x/cpumodel: model PTFF subfunctions
> for Multiple-epoch facility") -cpu help no longer shows the MSA8
> feature group. Turns out that we forgot to add the new MEPOCH_PTFF
> group enum.
>
> Fixes: 46a99c9f73c7 ("s3
On 20.03.2018 14:17, Christian Borntraeger wrote:
> David, Jason, Michael,
>
> the cpumodel code is somewhat fragile as we have to add maintain things
> in multiple places. I would like to have more robust code, e.g. by either
> generating more or by having build bug_ons or something like that.
>
On Thu, Mar 22, 2018 at 04:23:18PM -0500, Wei Huang wrote:
> Instead of using "1.0" as the system version of SMBIOS, we should use
> mc->name for mach-virt machine type to be consistent other architectures.
> With this patch, "dmidecode -t 1" (e.g., "-M virt-2.12,accel=kvm") will
> show:
>
> H
On 03/20/2018 02:07 PM, Christian Borntraeger wrote:
> Since commit 46a99c9f73c7 ("s390x/cpumodel: model PTFF subfunctions
> for Multiple-epoch facility") -cpu help no longer shows the MSA8
> feature group. Turns out that we forgot to add the new MEPOCH_PTFF
> group enum.
>
> Fixes: 46a99c9f73c7
applied to my s390-next branch.
On 03/14/2018 06:14 AM, Yi Min Zhao wrote:
> Currently we don't support pci multifunction. If a pci with
> multifucntion is plugged, the guest will spin forever. This patch fixes
> this.
>
> Signed-off-by: Yi Min Zhao
> Reviewed-by: Pierre Morel
> ---
> hw/s390
I'm not quite sure what the "for PowerNV only" in the subject is
supposed to be indicating.
On Thu, Mar 15, 2018 at 01:34:01PM +, Cédric Le Goater wrote:
> The HPTE bits definitions are slightly modified in ISA v3.0. Let's add
> some helpers to hide the differences in the hash MMU code.
>
> O
Just noticed that's a little old, you may need to rebase it
Thanks
On 03/23/2018 11:51 AM, Li Zhijian wrote:
On 03/21/2018 02:04 PM, Zhang Chen wrote:
Hi Suiheng,
I made a new guest image and retest it, and got the same bug from latest branch.
I found that after the COLO checkpoint begin,
Most of the RISC-V boards currently crash when they are started with
"-nodefaults", e.g.:
$ gdb --args riscv32-softmmu/qemu-system-riscv32 -nodefaults -M sifive_e
[...]
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
qemu_chr_fe_init ([...], s=s@entry=0x0, [...])
at chardev/char-f
On 03/23/2018 09:24 AM, David Gibson wrote:
> I'm not quite sure what the "for PowerNV only" in the subject is
> supposed to be indicating.
That's the initial subject which didn't evolve with the code, which is
now changing some sPAPR hcalls. And anyhow, hash MMU is supported on
POWER9 TCG, so th
On Thu, Mar 22, 2018 at 04:55:39PM +0200, Michael S. Tsirkin wrote:
> On Mon, Mar 19, 2018 at 03:15:31PM +0800, Tiwei Bie wrote:
> > This patch set does some small extensions to vhost-user protocol
> > to support VFIO based accelerators, and makes it possible to get
> > the similar performance of V
On 03/23/2018 09:36 AM, Thomas Huth wrote:
> Most of the RISC-V boards currently crash when they are started with
> "-nodefaults", e.g.:
>
> $ gdb --args riscv32-softmmu/qemu-system-riscv32 -nodefaults -M sifive_e
> [...]
> (gdb) r
> Program received signal SIGSEGV, Segmentation fault.
> qemu_chr_
Thanks zhijian.
On Fri, Mar 23, 2018 at 4:34 PM, Li Zhijian
wrote:
> Just noticed that's a little old, you may need to rebase it
>
>
> Thanks
>
>
> On 03/23/2018 11:51 AM, Li Zhijian wrote:
>
>>
>>
>> On 03/21/2018 02:04 PM, Zhang Chen wrote:
>>
>>> Hi Suiheng,
>>>
>>> I made a new guest image a
From: Yi Min Zhao
Currently we don't support pci multifunction. If a pci with
multifucntion is plugged, the guest will spin forever. This patch fixes
this.
Signed-off-by: Yi Min Zhao
Reviewed-by: Pierre Morel
Reviewed-by: Thomas Huth
Signed-off-by: Christian Borntraeger
---
hw/s390x/s390-pc
Since commit 46a99c9f73c7 ("s390x/cpumodel: model PTFF subfunctions
for Multiple-epoch facility") -cpu help no longer shows the MSA8
feature group. Turns out that we forgot to add the new MEPOCH_PTFF
group enum.
Fixes: 46a99c9f73c7 ("s390x/cpumodel: model PTFF subfunctions for
Multiple-epoch faci
Peter,
2 fixes for 2.12. Please pull
The following changes since commit d522e0bd18364f6d784d43edab35b0563d21f6f3:
gitmodules: Use the QEMU mirror of qemu-palcode (2018-03-22 19:24:16 +)
are available in the Git repository at:
git://github.com/borntraeger/qemu.git tags/s390x-20180323
On 22 March 2018 at 21:58, Laurent Vivier wrote:
> Some files like signal.c are really hard to read
> because all architectures are mixed in the same
> file.
>
> This series moves from signal.c these parts to
> the architecture dedicated directories in linux-user.
> Moerover, this allows to compar
On 22 March 2018 at 20:42, Philippe Mathieu-Daudé wrote:
> Hi Peter,
>
> On 03/22/2018 03:29 PM, Peter Maydell wrote:
>> On 22 March 2018 at 14:23, Andrew Jones wrote:
>>> On Thu, Mar 15, 2018 at 01:34:41PM +, Peter Maydell wrote:
If the GIC has the security extension support enabled, th
On Thu, Mar 22, 2018 at 03:38:13PM -0300, Eduardo Habkost wrote:
> On Thu, Mar 22, 2018 at 04:58:03PM +0300, Roman Kagan wrote:
> > On Thu, Mar 22, 2018 at 10:22:18AM -0300, Eduardo Habkost wrote:
> > > On Thu, Mar 22, 2018 at 04:00:14PM +0300, Roman Kagan wrote:
> > > > On Wed, Mar 21, 2018 at 05:
Hello,
I am currently trying to use nfs-vsocks on x86 for vitural machine
filesystem by some manuals on
https://www.spinics.net/lists/linux-nfs/msg64563.html
and https://lwn.net/Articles/647516/
It tells the quickstart steps with the following codes but I got some
problems as listed.
* Lin
On 23 March 2018 at 08:36, Thomas Huth wrote:
> Most of the RISC-V boards currently crash when they are started with
> "-nodefaults", e.g.:
>
> $ gdb --args riscv32-softmmu/qemu-system-riscv32 -nodefaults -M sifive_e
> [...]
> (gdb) r
> Program received signal SIGSEGV, Segmentation fault.
> qemu_c
Hi
On Fri, Mar 23, 2018 at 6:50 AM, Peter Xu wrote:
> On Thu, Mar 22, 2018 at 01:00:19PM +0100, Marc-André Lureau wrote:
>> Hi
>>
>> On Fri, Mar 9, 2018 at 10:00 AM, Peter Xu wrote:
>> > For those monitors who have enabled IO thread, we'll offload the
>> > responding procedure into IO thread. T
Hi
On Fri, Mar 23, 2018 at 6:18 AM, Peter Xu wrote:
> On Thu, Mar 22, 2018 at 11:22:14AM +0100, Marc-André Lureau wrote:
>> Hi
>>
>> On Fri, Mar 9, 2018 at 10:00 AM, Peter Xu wrote:
>> > Having "allow-oob" to true for a command does not mean that this command
>> > will always be run in out-of-ba
On Fri, Mar 23, 2018 at 3:43 AM, QingFeng Hao wrote:
> Test case 185 failed since commit 4486e89c219 --- "vl: introduce
> vm_shutdown()".
> It's because of the newly introduced function vm_shutdown calls
> bdrv_drain_all,
> which is called later by bdrv_close_all. bdrv_drain_all resumes the jobs
On Thu, Mar 22, 2018 at 05:42:02PM -0300, Philippe Mathieu-Daudé wrote:
> Hi Peter,
>
> On 03/22/2018 03:29 PM, Peter Maydell wrote:
> > On 22 March 2018 at 14:23, Andrew Jones wrote:
> >> On Thu, Mar 15, 2018 at 01:34:41PM +, Peter Maydell wrote:
> >>> If the GIC has the security extension s
On Thu, Mar 22, 2018 at 04:01:46PM -0300, Eduardo Habkost wrote:
> On Thu, Mar 22, 2018 at 02:13:58PM +0100, Vitaly Kuznetsov wrote:
> > We can also expose Hyper-V frequency MSRs when reenlightenment feature is
> > enabled and TSC frequency is known, Hyper-V on KVM will provide stable TSC
> > page
On 20 March 2018 at 22:25, Michael Clark wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The following changes since commit f1a63fcfcd92c88be8942b5ae71aef9749a4f135:
>
> Update version for v2.12.0-rc0 release (2018-03-20 19:04:22 +)
>
> are available in the git repository at:
>
On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote:
> Make sure all generated files go into qemu-build subdirectory.
> We can then include them like this:
> #include "qemu-build/trace.h"
>
> This serves two purposes:
> - make it easy to detect which files are in the source
> dir
Hi,
I observe a regression on KVM accelerated qemu-system-aarch64:
Unexpected error in kvm_device_access() at
/home/augere/UPSTREAM/qemu/accel/kvm/kvm-all.c:2164:
2018-03-23T09:59:59.629439Z qemu-system-aarch64: KVM_GET_DEVICE_ATTR
failed: Group 6 attr 0xc664: Device or resource busy
On 23 March 2018 at 10:24, Auger Eric wrote:
> Hi,
>
> I observe a regression on KVM accelerated qemu-system-aarch64:
>
> Unexpected error in kvm_device_access() at
> /home/augere/UPSTREAM/qemu/accel/kvm/kvm-all.c:2164:
> 2018-03-23T09:59:59.629439Z qemu-system-aarch64: KVM_GET_DEVICE_ATTR
> faile
Fix regression introduced in commit cf869d53172920536a14180a83292b240e9d0545:
Before:
{"execute":"foo"}
{"error": {"class": "CommandNotFound", "desc": "Expecting capabilities
negotiation with 'qmp_capabilities'"}}
After:
{"execute":"foo"}
{"error": {"class": "CommandNotFound", "desc": "The comma
On Thu 22 Mar 2018 05:12:26 PM CET, Laurent Vivier wrote:
> diff --git a/block/quorum.c b/block/quorum.c
> index 14333c18aa..304442ef65 100644
> --- a/block/quorum.c
> +++ b/block/quorum.c
> @@ -608,7 +608,7 @@ static void read_quorum_children_entry(void *opaque)
> static int read_quorum_children
On 16/03/2018 - 11:46:57, Thomas Huth wrote:
> On 27.11.2017 09:40, Eduardo Otubo wrote:
> > On Fri, Nov 24, 2017 at 06:44:59PM +0100, Thomas Huth wrote:
> >> Hi Eduardo,
> >>
> >> On 24.11.2017 14:46, Eduardo Otubo wrote:
> >>> v3:
> >>> * Removed all unecessary local_err
> >>> * Change return
On 20 March 2018 at 01:36, Trent Piepho wrote:
> Linux does not detect a break from this IMX serial driver as a magic
> sysrq. Nor does it note a break in the port error counts.
>
> The former is because the Linux driver uses the BRCD bit in the USR2
> register to trigger the RS-232 break handler
Am 23.03.2018 um 11:22 hat Daniel P. Berrangé geschrieben:
> On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote:
> > Make sure all generated files go into qemu-build subdirectory.
> > We can then include them like this:
> > #include "qemu-build/trace.h"
> >
> > This serves two pur
t; are available in the Git repository at:
>
> git://github.com/borntraeger/qemu.git tags/s390x-20180323
>
> for you to fetch changes up to 06a97edac172f52971d7bdca6bb56a1edcb1b8f6:
>
> s390x/cpumodel: fix feature groups and b
On 23 March 2018 at 03:58, Onur Sahin wrote:
> Hi all,
>
> I have noticed that the decoding part in ARM/A32 does not verify the
> opcodes for SWP instructions. The opcode field ([23:20]) for SWP
> instructions should be 0 or 4, and QEMU does not check against these
> values.
>
> Other opcode value
Hi,
On 23/03/18 11:26, Peter Maydell wrote:
> On 23 March 2018 at 10:24, Auger Eric wrote:
>> Hi,
>>
>> I observe a regression on KVM accelerated qemu-system-aarch64:
>>
>> Unexpected error in kvm_device_access() at
>> /home/augere/UPSTREAM/qemu/accel/kvm/kvm-all.c:2164:
>> 2018-03-23T09:59:59.62
On 21 March 2018 at 08:00, Shannon Zhao wrote:
> On 2018/3/20 19:54, Peter Maydell wrote:
>> Can you still successfully migrate a VM from a QEMU version
>> without this bugfix to one with the bugfix ?
>>
> I've tested this case. I can migrate a VM between these two versions.
Hmm. Looking at the c
As Max Reitz said, this breaks several qemu iotests. I can reproduce that on
s390
e.g. with ./check -qcow2 030 in the qemu-iotest.
Why was this merged?
On 03/09/2018 10:00 AM, Peter Xu wrote:
> Start to use dedicate IO thread for QMP monitors that are not using
> MUXed chardev.
>
> Reviewed-by
On 23 March 2018 at 12:01, Auger Eric wrote:
> Hi,
>
> On 23/03/18 11:26, Peter Maydell wrote:
>> On 23 March 2018 at 10:24, Auger Eric wrote:
>>> Hi,
>>>
>>> I observe a regression on KVM accelerated qemu-system-aarch64:
>>>
>>> Unexpected error in kvm_device_access() at
>>> /home/augere/UPSTREA
On 03/23/2018 01:11 PM, Peter Maydell wrote:
> On 23 March 2018 at 12:01, Auger Eric wrote:
>> Hi,
>>
>> On 23/03/18 11:26, Peter Maydell wrote:
>>> On 23 March 2018 at 10:24, Auger Eric wrote:
Hi,
I observe a regression on KVM accelerated qemu-system-aarch64:
Unexpecte
On Fri, Mar 23, 2018 at 12:11:17PM +, Peter Maydell wrote:
> On 23 March 2018 at 12:01, Auger Eric wrote:
> > Hi,
> >
> > On 23/03/18 11:26, Peter Maydell wrote:
> >> On 23 March 2018 at 10:24, Auger Eric wrote:
> >>> Hi,
> >>>
> >>> I observe a regression on KVM accelerated qemu-system-aarch
On Fri, Mar 23, 2018 at 01:01:43PM +0100, Auger Eric wrote:
> Hi,
>
> On 23/03/18 11:26, Peter Maydell wrote:
> > On 23 March 2018 at 10:24, Auger Eric wrote:
> >> Hi,
> >>
> >> I observe a regression on KVM accelerated qemu-system-aarch64:
> >>
> >> Unexpected error in kvm_device_access() at
> >
So we have a boot display when using a vgpu as primary display.
Use vfio-pci-ramfb instead of vfio-pci to enable it.
Signed-off-by: Gerd Hoffmann
---
include/hw/vfio/vfio-common.h | 2 ++
hw/vfio/display.c | 10 ++
hw/vfio/pci.c | 15 +++
3 files
Like virtio-vga, but using ramfb instead of legacy vga.
Signed-off-by: Gerd Hoffmann
---
hw/display/virtio-ramfb.c | 149 ++
hw/display/Makefile.objs | 2 +-
2 files changed, 150 insertions(+), 1 deletion(-)
create mode 100644 hw/display/virtio-ram
Hi,
Ok folks, here is a experimental patch series for a legacy free boot
framebuffer. If you want play with it I recommend getting the bits from
https://www.kraxel.org/cgit/qemu/log/?h=sirius/ramfb
because they come with an updated seabios and a new vgabios rom and an
experimental OVM
The boot framebuffer is expected to be configured by the firmware, so it
uses fw_cfg as interface. Initialization goes as follows:
(1) Check whenever etc/ramfb is present.
(2) Allocate framebuffer from RAM.
(3) Fill struct RAMFBCfg, write it to etc/ramfb.
Done. You can write stuff to the
Standalone device using ramfb. Intended for testing only. Offers
optional logging of vga port access, for debugging purposes.
Signed-off-by: Gerd Hoffmann
---
hw/display/ramfb-testdev.c | 96 ++
hw/display/Makefile.objs | 1 +
2 files changed, 97
source code: https://www.kraxe.org/cgit/seabios/log/?h=ramfb
---
pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes
pc-bios/bios.bin | Bin 131072 -> 131072 bytes
pc-bios/vgabios-ramfb.bin | Bin 0 -> 28160 bytes
3 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 pc
Like qxl-vga, but using ramfb instead of legacy vga.
NOT WORKING YET.
Also: Hackish proof-of-concept, with debug msgs.
Signed-off-by: Gerd Hoffmann
---
hw/display/qxl.h | 2 ++
hw/display/qxl.c | 47 +++
ui/spice-display.c | 6 ++
3 files c
On Fri, Mar 23, 2018 at 01:10:51PM +0100, Christian Borntraeger wrote:
> As Max Reitz said, this breaks several qemu iotests. I can reproduce that on
> s390
> e.g. with ./check -qcow2 030 in the qemu-iotest.
>
> Why was this merged?
My fault. Sorry. I should have done iotests before submission
On 23.03.2018 10:56, Peter Maydell wrote:
> On 23 March 2018 at 08:36, Thomas Huth wrote:
>> Most of the RISC-V boards currently crash when they are started with
>> "-nodefaults", e.g.:
>>
>> $ gdb --args riscv32-softmmu/qemu-system-riscv32 -nodefaults -M sifive_e
>> [...]
>> (gdb) r
>> Program re
Hi,
On 23/03/18 13:11, Peter Maydell wrote:
> On 23 March 2018 at 12:01, Auger Eric wrote:
>> Hi,
>>
>> On 23/03/18 11:26, Peter Maydell wrote:
>>> On 23 March 2018 at 10:24, Auger Eric wrote:
Hi,
I observe a regression on KVM accelerated qemu-system-aarch64:
Unexpected
22.03.2018 19:12, Laurent Vivier wrote:
> I've re-run some scripts from the coccinelle directory,
> and they have found some problems.
>
> This series fixes them.
>
> Laurent Vivier (4):
> error: Strip trailing '\n' from error string arguments (again again)
> error: Remove NULL checks on erro
On 23/03/2018 13:37, Michael Tokarev wrote:
> 22.03.2018 19:12, Laurent Vivier wrote:
>> I've re-run some scripts from the coccinelle directory,
>> and they have found some problems.
>>
>> This series fixes them.
>>
>> Laurent Vivier (4):
>> error: Strip trailing '\n' from error string arguments
On 03/23/2018 01:25 PM, Peter Xu wrote:
> On Fri, Mar 23, 2018 at 01:10:51PM +0100, Christian Borntraeger wrote:
>> As Max Reitz said, this breaks several qemu iotests. I can reproduce that on
>> s390
>> e.g. with ./check -qcow2 030 in the qemu-iotest.
>>
>> Why was this merged?
>
> My fault.
From: "Dr. David Alan Gilbert"
My rework of section adding combines overlapping or abutting regions,
but checks they're actually the same underlying RAM block.
Fix the case where two blocks abut but don't overlap; that new region
should get added (but not combined), but my previous patch was disa
Hi Peter,
On 23/03/18 13:19, Peter Xu wrote:
> On Fri, Mar 23, 2018 at 01:01:43PM +0100, Auger Eric wrote:
>> Hi,
>>
>> On 23/03/18 11:26, Peter Maydell wrote:
>>> On 23 March 2018 at 10:24, Auger Eric wrote:
Hi,
I observe a regression on KVM accelerated qemu-system-aarch64:
>
On Fri, Mar 23, 2018 at 01:36:36PM +0100, Auger Eric wrote:
> Hi,
>
> On 23/03/18 13:11, Peter Maydell wrote:
> > On 23 March 2018 at 12:01, Auger Eric wrote:
> >> Hi,
> >>
> >> On 23/03/18 11:26, Peter Maydell wrote:
> >>> On 23 March 2018 at 10:24, Auger Eric wrote:
> Hi,
>
> I
In order to guarantee compatibility on migration, QEMU should have
complete control over the features it announces to the guest via CPUID.
However, for a number of Hyper-V-related cpu properties, if the
corresponding feature is not supported by the underlying KVM, the
propery is silently ignored a
In order to guarantee compatibility on migration, QEMU should have
complete control over the features it announces to the guest via CPUID.
However, a number of Hyper-V-related features happen to depend on the
support in the underlying KVM, with no regard to QEMU configuration.
Make QEMU regain co
In order to guarantee compatibility on migration, QEMU should have
complete control over the features it announces to the guest via CPUID.
However, the declared availability of Hyper-V frequency MSRs
(HV_X64_MSR_TSC_FREQUENCY and HV_X64_MSR_APIC_FREQUENCY) depends solely
on the support for them in
On Fri, Mar 23, 2018 at 01:44:54PM +0100, Christian Borntraeger wrote:
>
>
> On 03/23/2018 01:25 PM, Peter Xu wrote:
> > On Fri, Mar 23, 2018 at 01:10:51PM +0100, Christian Borntraeger wrote:
> >> As Max Reitz said, this breaks several qemu iotests. I can reproduce that
> >> on s390
> >> e.g. wi
On 23 March 2018 at 12:31, Thomas Huth wrote:
> On 23.03.2018 10:56, Peter Maydell wrote:
>> On 23 March 2018 at 08:36, Thomas Huth wrote:
>>> Most of the RISC-V boards currently crash when they are started with
>>> "-nodefaults", e.g.:
>>>
>>> $ gdb --args riscv32-softmmu/qemu-system-riscv32 -no
Change frequency of the core used in tests so that clock cycle takes
exactly 64ns. Change icount power used in tests to 6, so that each
instruction takes exactly 1 clock cycle. With these changes the
assumptions of the xtensa timers test are correct and the test must
always pass.
Longer story:
h
On 23 March 2018 at 13:01, Peter Xu wrote:
> On Fri, Mar 23, 2018 at 01:44:54PM +0100, Christian Borntraeger wrote:
>>
>>
>> On 03/23/2018 01:25 PM, Peter Xu wrote:
>> > On Fri, Mar 23, 2018 at 01:10:51PM +0100, Christian Borntraeger wrote:
>> >> As Max Reitz said, this breaks several qemu iotests
On 03/23/2018 02:01 PM, Peter Xu wrote:
> On Fri, Mar 23, 2018 at 01:44:54PM +0100, Christian Borntraeger wrote:
>>
>>
>> On 03/23/2018 01:25 PM, Peter Xu wrote:
>>> On Fri, Mar 23, 2018 at 01:10:51PM +0100, Christian Borntraeger wrote:
As Max Reitz said, this breaks several qemu iotests. I
Adding Ard and Marc, and keeping the context undisturbed for his sake.
Comments at the bottom.
On 03/23/18 13:25, Gerd Hoffmann wrote:
> Hi,
>
> Ok folks, here is a experimental patch series for a legacy free boot
> framebuffer. If you want play with it I recommend getting the bits from
>
>
On 23 March 2018 at 07:48, Andrew Jones wrote:
> On Thu, Mar 22, 2018 at 04:23:18PM -0500, Wei Huang wrote:
>> Instead of using "1.0" as the system version of SMBIOS, we should use
>> mc->name for mach-virt machine type to be consistent other architectures.
>> With this patch, "dmidecode -t 1" (e.
On Fri, Mar 23, 2018 at 02:23:27PM +0100, Christian Borntraeger wrote:
>
>
> On 03/23/2018 02:01 PM, Peter Xu wrote:
> > On Fri, Mar 23, 2018 at 01:44:54PM +0100, Christian Borntraeger wrote:
> >>
> >>
> >> On 03/23/2018 01:25 PM, Peter Xu wrote:
> >>> On Fri, Mar 23, 2018 at 01:10:51PM +0100, Ch
On Fri, Mar 23, 2018 at 10:22:27AM +, Daniel P. Berrangé wrote:
> On Thu, Mar 22, 2018 at 09:27:55PM +0200, Michael S. Tsirkin wrote:
> > Make sure all generated files go into qemu-build subdirectory.
> > We can then include them like this:
> > #include "qemu-build/trace.h"
> >
> > This serve
On 23/03/2018 14:12, Peter Maydell wrote:
> I think that the latter seems to be what the design intends:
> a backend with a NULL chardev pointer is "backend with no
> chardev attached at the moment". At least some of our UART devices
> handle that as "just dump output into nothingness", which
> see
On 23 March 2018 at 14:02, Paolo Bonzini wrote:
> However, if the machine is emulating a real-world board with a fixed SoC
> and fixed hardware in the SoC, it makes more sense to create a null backend.
That's a lot of duplicate code to say "oh, this is NULL, create the
null backend" in lots of d
Temporarily disable OOB for 2.12 since it break (a lot of) things.
Luckily it's only a switch so not so hard. Meanwhile, revert all new
tests that checks against it.
Tests done: all target builds and "make check" passed, but only on
x86_64 host. It can pass all "raw" iotests, but some "qcow2" iot
This reverts commit d003f7a8f9cafe50119975844fa01afc2baf41fb.
Signed-off-by: Peter Xu
---
tests/qmp-test.c | 65
1 file changed, 65 deletions(-)
diff --git a/tests/qmp-test.c b/tests/qmp-test.c
index 07c0b87e27..2e4b599a4c 100644
--- a/te
This reverts commit 3fd2457d18edf5736f713dfe1ada9c87a9badab1.
Signed-off-by: Peter Xu
---
monitor.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index 6ccd2fc089..77f4c41cfa 100644
--- a/monitor.c
+++ b/monitor.c
@@ -36,7 +36,6 @@
#include "net/s
This reverts commit 91ad45061af0fe44ac5dadb5bedaf4d7a08077c8.
Signed-off-by: Peter Xu
---
tests/qmp-test.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/tests/qmp-test.c b/tests/qmp-test.c
index 2e4b599a4c..d1fa1cb217 100644
--- a/tests/qmp-test.c
+++ b/tests/qmp-tes
Revert the tests in the patch 02130314d8 ("qmp: introduce
QMPCapability", 2018-03-19) since we'll disable OOB for now.
Signed-off-by: Peter Xu
---
tests/qmp-test.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/tests/qmp-test.c b/tests/qmp-test.c
index d1fa1cb217..
On 23/03/2018 15:04, Peter Maydell wrote:
>> However, if the machine is emulating a real-world board with a fixed SoC
>> and fixed hardware in the SoC, it makes more sense to create a null backend.
>
> That's a lot of duplicate code to say "oh, this is NULL, create the
> null backend" in lots of di
On 22 March 2018 at 21:58, Laurent Vivier wrote:
> Signed-off-by: Laurent Vivier
> ---
> linux-user/signal.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/linux-user/signal.c b/linux-user/signal.c
> index 2c08ca14cf..514145b299 100644
> --- a/linux-user/signal
On Fri, Mar 23, 2018 at 10:08:17PM +0800, Peter Xu wrote:
> Temporarily disable OOB for 2.12 since it break (a lot of) things.
> Luckily it's only a switch so not so hard. Meanwhile, revert all new
> tests that checks against it.
>
> Tests done: all target builds and "make check" passed, but only
On 22 March 2018 at 21:58, Laurent Vivier wrote:
> instead of calling setup_frame() conditionnaly to a list of knowm targets,
"Instead". "conditionally". "known".
> define TARGET_ARCH_HAS_SETUP_FRAME if the target provides the function
> and call it only if the macro is defined
Trailing ".".
>
On 22 March 2018 at 21:58, Laurent Vivier wrote:
> move all target specific parts to
> signal.inc.c in arch directory
>
> Signed-off-by: Laurent Vivier
> ---
> linux-user/aarch64/signal.inc.c| 556 +++
> linux-user/alpha/signal.inc.c | 258 ++
> linux-user/arm/signal.inc.c| 7
On Fri, Mar 23, 2018 at 12:46:37PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> My rework of section adding combines overlapping or abutting regions,
> but checks they're actually the same underlying RAM block.
> Fix the case where two blocks abut but don't over
On 23 March 2018 at 14:13, Paolo Bonzini wrote:
> On 23/03/2018 15:04, Peter Maydell wrote:
>>> However, if the machine is emulating a real-world board with a fixed SoC
>>> and fixed hardware in the SoC, it makes more sense to create a null backend.
>>
>> That's a lot of duplicate code to say "oh,
From: Daniel P. Berrangé
When doing a build with builddir != srcdir, if any generated files are
accidentally present in srcdir from a previous build, these can cause
unexpected failures.
Currently there is a rule that checks for existance of config-host.mak,
but there have been cases where confi
I've re-run some scripts from the coccinelle directory,
and they have found some problems.
This series fixes them.
v2: only change PATCH 4/4
- keep comments
- fix indentation
I didn't remove changes in autogenerated files as it
seems they are generated only once.
Daniel P. Berrangé (1):
Re-run Coccinelle patch
scripts/coccinelle/error_propagate_null.cocci
Signed-off-by: Laurent Vivier
---
io/channel-websock.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/io/channel-websock.c b/io/channel-websock.c
index ec48a305f0..e6608b969d 100644
--- a/io/channel-web
Re-run Coccinelle script scripts/coccinelle/return_directly.cocci
Signed-off-by: Laurent Vivier
---
accel/tcg/translate-all.c | 5 +-
block/quorum.c | 6 +--
hw/arm/exynos4210.c| 6 +--
hw/block/vhost
Re-run Coccinelle script scripts/coccinelle/err-bad-newline.cocci,
and found new error_report() occurences with '\n'.
Signed-off-by: Laurent Vivier
---
target/i386/hvf/hvf.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/target/i386/hvf/hvf.c b/tar
Re-run Coccinelle script scripts/coccinelle/qobject.cocci
Signed-off-by: Laurent Vivier
---
block/nvme.c | 11 +--
monitor.c| 2 +-
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/block/nvme.c b/block/nvme.c
index 8bca57aae6..c4f3a7bc94 100644
--- a/block/nvme.c
+++ b
On 03/23/2018 03:15 PM, Peter Xu wrote:
> On Fri, Mar 23, 2018 at 10:08:17PM +0800, Peter Xu wrote:
>> Temporarily disable OOB for 2.12 since it break (a lot of) things.
>> Luckily it's only a switch so not so hard. Meanwhile, revert all new
>> tests that checks against it.
>>
>> Tests done: all
On Fri, Mar 23, 2018 at 12:46:37PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> My rework of section adding combines overlapping or abutting regions,
> but checks they're actually the same underlying RAM block.
> Fix the case where two blocks abut but don't over
Eduardo Habkost writes:
> On Thu, Mar 22, 2018 at 02:13:58PM +0100, Vitaly Kuznetsov wrote:
>> We can also expose Hyper-V frequency MSRs when reenlightenment feature is
>> enabled and TSC frequency is known, Hyper-V on KVM will provide stable TSC
>> page clocksources to its guests.
>>
>> Signed-
Hi,
> I believe the only point of this device model (and the associated guest
> fw driver) is Windows-on-KVM/aarch64.
The other one is vgpu boot display.
And maybe killing vga emulation. Well, at least be able to not use it
any more for UEFI guests. It's so much crazy stuff in vga emulation
* Michael S. Tsirkin (m...@redhat.com) wrote:
> On Fri, Mar 23, 2018 at 12:46:37PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > My rework of section adding combines overlapping or abutting regions,
> > but checks they're actually the same underlying RAM bl
On 23/03/2018 15:28, Peter Maydell wrote:
>> Note it's a null "backend", not necessarily a null "character device".
>> Your proposal, namely ensuring that be->chr == NULL is handled properly
>> in qemu_chr_fe_init, would be just fine.
>
> Hmm, the chardev layer code seems to have more ends than I
On 03/23/18 15:51, Gerd Hoffmann wrote:
> Hi,
>
>> I believe the only point of this device model (and the associated guest
>> fw driver) is Windows-on-KVM/aarch64.
>
> The other one is vgpu boot display.
Interesting. I know nearly nothing about vgpu, but I hoped it'd come
with its own UEFI GOP
On Fri, Mar 23, 2018 at 02:53:38PM +, Dr. David Alan Gilbert wrote:
> * Michael S. Tsirkin (m...@redhat.com) wrote:
> > On Fri, Mar 23, 2018 at 12:46:37PM +, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > My rework of section adding combines over
1 - 100 of 234 matches
Mail list logo
