On 28.11.19 16:05, Peter Maydell wrote:
> On Thu, 28 Nov 2019 at 12:48, Christian Borntraeger
> wrote:
>>
>>
>>
>> On 28.11.19 13:45, Cornelia Huck wrote:
>>> On Thu, 28 Nov 2019 13:35:29 +0100
>>> Christian Borntraeger wrote:
>>>
>
On 28.11.19 14:16, Cornelia Huck wrote:
> On Thu, 28 Nov 2019 14:11:38 +0100
> Thomas Huth wrote:
>
>> On 28/11/2019 13.35, Christian Borntraeger wrote:
>>> Ack.
>>>
>>> Conny, I think this would be really nice to have for 4.2 (together with a
>&g
On 28.11.19 13:45, Cornelia Huck wrote:
> On Thu, 28 Nov 2019 13:35:29 +0100
> Christian Borntraeger wrote:
>
>> Ack.
>>
>> Conny, I think this would be really nice to have for 4.2 (together with a
>> bios rebuild)
>> as this fixes a regression. Opinio
Ack.
Conny, I think this would be really nice to have for 4.2 (together with a bios
rebuild)
as this fixes a regression. Opinions?
On 28.11.19 13:33, Claudio Imbrenda wrote:
> The existing s390 bios gets the LOADPARM information from the system using
> an SCLP call that specifies a buffer
re-adding ccs from the cover-letter
>>> On 25.11.19 18:20, David Hildenbrand wrote:
>>>
>>> As soon as dynamic feature groups are used, the CPU model becomes
>>> migration-unsafe. Upper layers can expand these models to migration-safe
>>> and static variants, allowing them to be migrated.
>>
>> I
On 25.11.19 18:20, David Hildenbrand wrote:
>
> As soon as dynamic feature groups are used, the CPU model becomes
> migration-unsafe. Upper layers can expand these models to migration-safe
> and static variants, allowing them to be migrated.
I really dislike that. I am trying to get rid of
On 21.11.19 15:28, David Hildenbrand wrote:
>> And please trim your emails.
>>
>
> If you use Thunderbird I suggest QuoteCollapse ... because nobody got time
> for that ;)
neat.
On 25.10.19 09:17, David Hildenbrand wrote:
> On 25.10.19 04:25, Eduardo Habkost wrote:
>> We had introduced versioned CPU models in QEMU 4.1, including a
>> method for querying for CPU model versions using
>
> Interesting, I was not aware of that.
>
> On s390x, we somewhat have versioned CPU
On 17.10.19 17:18, David Hildenbrand wrote:
> On 17.10.19 17:16, Jiri Denemark wrote:
>> Hi David and David,
>>
>> I'm working on libvirt's support [1] for query-machines'
>> default-cpu-type, which is supposed to return the type of the default
>> CPU model that QEMU uses for each machine type.
On 17.10.19 16:21, Thomas Huth wrote:
> There is no USB on s390x, so running qemu-system-s390x with
> "-machine ...,usb=on" is certainly wrong. Emit a warning to make
> the users aware of their misconfiguration.
>
> Signed-off-by: Thomas Huth
> ---
> After a year or two, we could finally
On 04.10.19 14:36, Daniel P. Berrangé wrote:
> On Fri, Oct 04, 2019 at 02:18:49PM +0200, Christian Borntraeger wrote:
>>
>>
>> On 04.10.19 14:13, Paolo Bonzini wrote:
>>> On 04/10/19 14:03, Christian Borntraeger wrote:
>>>> Stefano, Paolo,
&g
Stefano, Paolo,
I have an interesting fail in QEMU
2019-10-04T12:00:32.675188Z qemu-system-s390x: GLib: g_mapped_file_unref:
assertion 'file != NULL' failed
that bisected to
commit 816b9fe450220e19acb91a0ce4a8ade7000648d1 (refs/bisect/bad)
elf-ops.h: Map into memory the ELF to load
On 04.10.19 14:13, Paolo Bonzini wrote:
> On 04/10/19 14:03, Christian Borntraeger wrote:
>> Stefano, Paolo,
>>
>> I have an interesting fail in QEMU
>>
>> 2019-10-04T12:00:32.675188Z qemu-system-s390x: GLib: g_mapped_file_unref:
>> assertion
On 02.10.19 18:01, Kevin Wolf wrote:
> Am 30.09.2019 um 15:19 hat Christian Borntraeger geschrieben:
>> From: Paolo Bonzini
>>
>> Currently MemoryRegionSection has 1:1 mapping to KVMSlot.
>> However next patch will allow splitting MemoryRegionSection into
>
hew Rosato
Message-Id: <1569507036-15314-1-git-send-email-mjros...@linux.ibm.com>
Signed-off-by: Christian Borntraeger
---
hw/s390x/s390-pci-bus.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
index 963a41c7f5
bre...@linux.ibm.com>
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
hw/s390x/event-facility.c | 3 ---
hw/s390x/sclp.c | 17 -
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/hw/s390x/event-facility.c b/hw/s390x/event-facility.c
Acked-by: Paolo Bonzini
Signed-off-by: Christian Borntraeger
[fixup line break]
---
accel/kvm/kvm-all.c | 103
1 file changed, 57 insertions(+), 46 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index b09bad08048d..a85ec09486dd
bre...@linux.ibm.com>
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
hw/s390x/sclp.c | 12
1 file changed, 12 insertions(+)
diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index abb6e5011f9c..f57ce7b73943 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/
Mammedov
Reviewed-by: Peter Xu
Message-Id: <20190924144751.24149-3-imamm...@redhat.com>
Acked-by: Paolo Bonzini
Signed-off-by: Christian Borntraeger
---
accel/kvm/kvm-all.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/accel/k
From: Matthew Rosato
As discussed previously with Collin, I will take over maintaining
s390 pci.
Signed-off-by: Matthew Rosato
Message-Id: <1569590461-12562-1-git-send-email-mjros...@linux.ibm.com>
Acked-by: Collin Walling
Signed-off-by: Christian Borntraeger
---
MAINTAINERS | 2 +-
From: Janosch Frank
All sclp codes need to be checked for page boundary violations.
Signed-off-by: Janosch Frank
Reviewed-by: Jason J. Herne
Message-Id: <1569591203-15258-3-git-send-email-imbre...@linux.ibm.com>
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
-
)
Christian Borntraeger (1):
s390/kvm: split kvm mem slots at 4TB
Claudio Imbrenda (1):
s390x: sclp: Report insufficient SCCB length
Igor Mammedov (2):
kvm: split too big memory section on several memslots
s390: do not call
memory_region_allocate_system_memory() API
and eventually use a single hostmem backend for guest RAM.
Signed-off-by: Igor Mammedov
Message-Id: <20190924144751.24149-4-imamm...@redhat.com>
Reviewed-by: Peter Xu
Acked-by: Paolo Bonzini
Signed-off-by: Christian Borntraeger
---
accel/kvm/kvm-all.c
Instead of splitting at an unaligned address, we can simply split at
4TB.
Signed-off-by: Christian Borntraeger
Acked-by: Igor Mammedov
---
target/s390x/kvm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 54864c259c5e
all memory_region_allocate_system_memory()
multiple times
Signed-off-by: Igor Mammedov
Message-Id: <20190924144751.24149-5-imamm...@redhat.com>
Acked-by: Peter Xu
Signed-off-by: Christian Borntraeger
---
hw/s390x/s390-virtio-ccw.c | 30 +++---
target/s390x/kvm.c | 11 +
m the
list of supported CPUs.
Signed-off-by: Thomas Huth
Message-Id: <20190928190334.6897-1-th...@redhat.com>
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
in
From: Janosch Frank
Requests over 4k are not a spec exception.
Signed-off-by: Janosch Frank
Reviewed-by: Jason J. Herne
Message-Id: <1569591203-15258-4-git-send-email-imbre...@linux.ibm.com>
Acked-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
hw/s390x/sclp.c | 3
On 24.09.19 16:47, Igor Mammedov wrote:
> Changelog:
> since v6:
> - include and rebase on top of
>[PATCH 0/2] kvm: clear dirty bitmaps from all overlapping memslots
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg646200.html
> - minor fixups suggested during v6
On 24.09.19 16:47, Igor Mammedov wrote:
> From: Paolo Bonzini
>
> We may need to clear the dirty bitmap for more than one KVM memslot.
> First do some code movement with no semantic change.
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Igor Mammedov
> Reviewed-by: Peter Xu
> ---
>
On 28.09.19 21:03, Thomas Huth wrote:
> On IBM Z, KVM in the kernel is only implemented for 64-bit mode, and
> with regards to TCG, we also only support 64-bit host CPUs (see the
> check at the beginning of tcg/s390/tcg-target.inc.c), so we should
> remove s390 (without "x", i.e. the old 31-bit
On 30.09.19 11:33, Igor Mammedov wrote:
> On Mon, 30 Sep 2019 09:09:59 +0200
> Christian Borntraeger wrote:
>
>> On 28.09.19 03:28, Peter Xu wrote:
>>> On Fri, Sep 27, 2019 at 03:33:20PM +0200, Igor Mammedov wrote:
>>>> On Thu, 26 Sep 2019
gt;
> Right, I think if so hard code would be fine for now, and probably can
> with a smallest one across all archs (should depend on the smallest
> page size, I guess).
>
>>
>> Then there wouldn't be need for having machine specific code
>> to care about it and pick/se
On 26.09.19 16:10, Matthew Rosato wrote:
> The fix in dbe9cf606c shrinks the IOMMU memory region to a size
> that seems reasonable on the surface, however is actually too
> small as it is based against a 0-mapped address space. This
> causes breakage with small guests as they can overrun the
On 27.09.19 15:33, Claudio Imbrenda wrote:
> From: Janosch Frank
>
> Requests over 4k are not a spec exception.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Jason J. Herne
> ---
> hw/s390x/sclp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/hw/s390x/sclp.c
On 27.09.19 15:33, Claudio Imbrenda wrote:
> Return the correct error code when the SCCB buffer is too small to
> contain all of the output, for the Read SCP Information and
> Read CPU Information commands.
>
> Signed-off-by: Claudio Imbrenda
> Reviewed-by: Jason J. Herne
> ---
>
On 27.09.19 15:33, Claudio Imbrenda wrote:
> From: Janosch Frank
>
> All sclp codes need to be checked for page boundary violations.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Jason J. Herne
> ---
> hw/s390x/sclp.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
On 27.09.19 15:33, Claudio Imbrenda wrote:
> From: Janosch Frank
>
> Invalid command checking has to be done before the boundary check,
> refactoring it now allows to insert the boundary check at the correct
> place later.
>
> Signed-off-by: Janosch Frank
> Reviewed-by: Jason J. Herne
>
On 27.09.19 15:21, Matthew Rosato wrote:
> As discussed previously with Collin, I will take over maintaining
> s390 pci.
>
> Signed-off-by: Matthew Rosato
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index
On 26.09.19 16:10, Matthew Rosato wrote:
> The fix in dbe9cf606c shrinks the IOMMU memory region to a size
> that seems reasonable on the surface, however is actually too
> small as it is based against a 0-mapped address space. This
> causes breakage with small guests as they can overrun the
On 26.09.19 16:34, Peter Maydell wrote:
> On Thu, 26 Sep 2019 at 15:12, Matthew Rosato wrote:
>>
>> The fix in dbe9cf606c shrinks the IOMMU memory region to a size
>> that seems reasonable on the surface, however is actually too
>> small as it is based against a 0-mapped address space. This
On 26.09.19 14:58, Daniel P. Berrangé wrote:
> On Thu, Sep 26, 2019 at 08:50:36AM +0100, Peter Maydell wrote:
>> On Thu, 26 Sep 2019 at 00:31, Alex Bennée wrote:
>>>
>>> The 32 bit hosts are already a second class citizen especially with
>>> support for running 64 bit guests under TCG. We are
On 24.09.19 14:44, Sergio Lopez wrote:
> Microvm is a machine type inspired by both NEMU and Firecracker, and
> constructed after the machine model implemented by the latter.
>
> It's main purpose is providing users a minimalist machine type free
> from the burden of legacy compatibility,
mslots
>
> include/sysemu/kvm_int.h | 1 +
> accel/kvm/kvm-all.c | 238 +++--
> hw/s390x/s390-virtio-ccw.c | 30 +
> target/s390x/kvm.c | 11 ++
> 4 files changed, 161 insertions(+), 119 deletions(-)
>
Series
Teste
From: Thomas Huth
The new image now contains the "pc-bios/s390-ccw/net: fix a possible
memory leak in get_uuid()" patch.
Signed-off-by: Thomas Huth
---
pc-bios/s390-netboot.img | Bin 67232 -> 67232 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/pc-bios/s390-netboot.img
: <20190913091443.27565-1-th...@redhat.com>
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
hw/intc/s390_flic_kvm.c | 6 --
hw/intc/trace-events| 1 -
target/s390x/kvm.c | 7 +++
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/h
We now know that gen15a is called z15.
Reviewed-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
target/s390x/cpu_models.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 1d16d7d5e794..009afc38b92d
From: Yifan Luo
There is a possible memory leak in get_uuid(). Should free allocated mem
before
return NULL.
Signed-off-by: Yifan Luo
Message-Id: <02cf01d55267$86cf2850$946d78f0$@cmss.chinamobile.com>
Reviewed-by: Thomas Huth
Reviewed-by: Cornelia Huck
Signed-off-by: Thomas Huth
---
)
- bugfixes in ccw bios
- gen15a is called z15
- officially require a 3.15 kernel or later for kvm
Christian Borntraeger (2):
Merge tag 's390-ccw-bios-2019-09-18' of https://gitlab.com/huth/qemu into
s390-next
s390x/cpumodel
From: Thomas Huth
Since commit 339686a358b11a231aa5b6d1424e7a1460d7f277 ("pc-bios/s390-ccw:
zero out bss section"), we are clearing now the BSS in start.S, so there
is no need to pre-initialize the loadparm_str array with zeroes anymore.
Reviewed-by: Cornelia Huck
Signed-off-by: Thomas Huth
We now know that gen15a is called z15.
Signed-off-by: Christian Borntraeger
---
target/s390x/cpu_models.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 1d16d7d5e794..009afc38b92d 100644
--- a/target/s390x
On 02.09.19 15:49, Igor Mammedov wrote:
> On Fri, 30 Aug 2019 18:19:29 +0200
> Christian Borntraeger wrote:
>
>> On 30.08.19 11:41, Igor Mammedov wrote:
>>> On Thu, 29 Aug 2019 14:41:13 +0200
>>> Christian Borntraeger wrote:
>>>
>>>>
On 30.08.19 11:41, Igor Mammedov wrote:
> On Thu, 29 Aug 2019 14:41:13 +0200
> Christian Borntraeger wrote:
>
>> On 29.08.19 14:31, Igor Mammedov wrote:
>>> On Thu, 29 Aug 2019 14:07:44 +0200
>>> Christian Borntraeger wrote:
>>>
>>>>
On 29.08.19 14:31, Igor Mammedov wrote:
> On Thu, 29 Aug 2019 14:07:44 +0200
> Christian Borntraeger wrote:
>
>> On 29.08.19 14:04, Igor Mammedov wrote:
>>> On Thu, 29 Aug 2019 08:47:49 +0200
>>> Christian Borntraeger wrote:
>>>
>>>>
On 29.08.19 14:04, Igor Mammedov wrote:
> On Thu, 29 Aug 2019 08:47:49 +0200
> Christian Borntraeger wrote:
>
>> On 27.08.19 14:56, Igor Mammedov wrote:
>>> On Tue, 20 Aug 2019 18:07:27 +0200
>>> Cornelia Huck wrote:
>>>
>>>> On Wed
ventually use a single hostmem backend for guest RAM.
>>>
>>> Signed-off-by: Igor Mammedov
>>> ---
>>> v5:
>>> * move computation 'size -= slot_size' inside of loop body
>>> (David Hildenbrand )
>>> v4:
>>> * fix comp
On 28.08.19 15:47, Cornelia Huck wrote:
> On Wed, 28 Aug 2019 15:42:37 +0200
> Thomas Huth wrote:
>
>> On 28/08/2019 15.27, Christian Borntraeger wrote:
>>> On 28.08.19 14:33, Thomas Huth wrote:
>>>> We're clearing the BSS in start.S now, so the
Author: Christian Borntraeger
AuthorDate: Wed Nov 22 15:26:27 2017 +0100
Commit: Cornelia Huck
CommitDate: Thu Dec 14 17:56:54 2017 +0100
pc-bios/s390-ccw: zero out bss section
>
> Signed-off-by: Thomas Huth
> ---
> pc-bios/s390-ccw/main.c | 2 +-
> 1 file chang
On 02.08.19 16:59, Christian Borntraeger wrote:
>
>
> On 02.08.19 16:42, Christian Borntraeger wrote:
>> On 02.08.19 15:32, Igor Mammedov wrote:
>>> Changelog:
>>> since v2:
>>> - break migration from old QEMU (since 2.12-4.1) for guest w
On 02.08.19 16:42, Christian Borntraeger wrote:
> On 02.08.19 15:32, Igor Mammedov wrote:
>> Changelog:
>> since v2:
>> - break migration from old QEMU (since 2.12-4.1) for guest with >8TB RAM
>> and drop migratable aliases patch as was agreed duri
On 02.08.19 15:32, Igor Mammedov wrote:
> Changelog:
> since v2:
> - break migration from old QEMU (since 2.12-4.1) for guest with >8TB RAM
> and drop migratable aliases patch as was agreed during v2 review
> - drop 4.2 machines patch as it's not prerequisite anymore
> since v1:
On 02.08.19 15:32, Igor Mammedov wrote:
> Max memslot size supported by kvm on s390 is 8Tb,
> move logic of splitting RAM in chunks upto 8T to KVM code.
>
> This way it will hide KVM specific restrictions in KVM code
> and won't affect baord level design decisions. Which would allow
> us to
On 02.08.19 15:36, David Hildenbrand wrote:
> On 02.08.19 15:32, Igor Mammedov wrote:
>> s390 was trying to solve limited KVM memslot size issue by abusing
>> memory_region_allocate_system_memory(), which breaks API contract
>> where the function might be called only once.
>>
>> Beside an
On 02.08.19 13:40, Igor Mammedov wrote:
> On Fri, 2 Aug 2019 12:27:50 +0200
> Christian Borntraeger wrote:
>
>> On 02.08.19 12:25, David Hildenbrand wrote:
>>> On 02.08.19 11:38, Igor Mammedov wrote:
>>>> s390 was trying to solve limit
On 02.08.19 12:25, David Hildenbrand wrote:
> On 02.08.19 11:38, Igor Mammedov wrote:
>> s390 was trying to solve limited KVM memslot size issue by abusing
>> memory_region_allocate_system_memory(), which breaks API contract
>> where the function might be called only once.
>>
>> s390 should
On 02.08.19 10:37, David Hildenbrand wrote:
> On 02.08.19 10:29, Christian Borntraeger wrote:
>>
>>
>> On 02.08.19 10:04, David Hildenbrand wrote:
>>> On 29.07.19 16:52, Igor Mammedov wrote:
>>>> While looking into unifying guest RAM allocation to
On 02.08.19 10:04, David Hildenbrand wrote:
> On 29.07.19 16:52, Igor Mammedov wrote:
>> While looking into unifying guest RAM allocation to use hostmem backends
>> for initial RAM (especially when -mempath is used) and retiring
>> memory_region_allocate_system_memory() API, leaving only single
On 31.07.19 14:28, Christian Borntraeger wrote:
>
>
> On 31.07.19 14:04, Andrey Shinkevich wrote:
>> On 31/07/2019 10:24, Christian Borntraeger wrote:
>>>
>>>
>>> On 30.07.19 21:20, Paolo Bonzini wrote:
>>>> On 30/07/19 18:01,
On 31.07.19 14:04, Andrey Shinkevich wrote:
> On 31/07/2019 10:24, Christian Borntraeger wrote:
>>
>>
>> On 30.07.19 21:20, Paolo Bonzini wrote:
>>> On 30/07/19 18:01, Andrey Shinkevich wrote:
>>>> Not the whole structure is initialized before pas
On 30.07.19 21:20, Paolo Bonzini wrote:
> On 30/07/19 18:01, Andrey Shinkevich wrote:
>> Not the whole structure is initialized before passing it to the KVM.
>> Reduce the number of Valgrind reports.
>>
>> Signed-off-by: Andrey Shinkevich
>
> Christian, is this the right fix? It's not
On 30.07.19 19:14, Philippe Mathieu-Daudé wrote:
> On 7/30/19 7:05 PM, Christian Borntraeger wrote:
>> On 30.07.19 18:44, Philippe Mathieu-Daudé wrote:
>>> On 7/30/19 6:01 PM, Andrey Shinkevich wrote:
>>>> Not the whole structure is initialized before pass
On 30.07.19 18:46, Peter Maydell wrote:
> On Tue, 30 Jul 2019 at 17:05, Andrey Shinkevich
> wrote:
>>
>> Not the whole structure is initialized before passing it to the KVM.
>> Reduce the number of Valgrind reports.
>>
>> Signed-off-by: Andrey Shinkevich
>
> Does it even make sense to try to
PUState *cs)
>> return 0;
>> }
>>
>> +memset(_data, 0, sizeof(msr_data));
>
> I wonder the overhead of this one...
Cant we use designated initializers like in
commit bdfc8480c50a53d91aa9a513d23a84de0d5fbc86
Author: Christian Borntraeger
A
I remember that you send a similar patch a while ago and something broke on
s390x.
Have you changed something from the old patchs set?
On 29.07.19 16:52, Igor Mammedov wrote:
> While looking into unifying guest RAM allocation to use hostmem backends
> for initial RAM (especially when -mempath is
On 24.07.19 10:25, Andrey Shinkevich wrote:
> The patch "iotests: Set read-zeroes on in null block driver for Valgrind"
> needs the change in 051.out when compared against on the s390 system.
>
> Reported-by: Christian Borntraeger
Tested-by: Christian Borntraeger
FWIW
On 24.07.19 09:30, Andrey Shinkevich wrote:
>
>
> On 24/07/2019 10:18, Christian Borntraeger wrote:
>>
>> On 19.07.19 15:43, Kevin Wolf wrote:
>>> From: Andrey Shinkevich
>>>
>>> The Valgrind tool reports about the uninitialised buffer 'bu
On 19.07.19 15:43, Kevin Wolf wrote:
> From: Andrey Shinkevich
>
> The Valgrind tool reports about the uninitialised buffer 'buf'
> instantiated on the stack of the function guess_disk_lchs().
> Pass 'read-zeroes=on' to the null block driver to make it deterministic.
> The output of the tests
qemu_system_reset_request(SHUTDOWN_CAUSE_NONE);
>> } else {
>> qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
>> }
>>
>> would also work.
>
> If that works for you, then you could take out the test in the reset
> code. You would have to modify qemu_system_reset_request too of course.
>
> But it seems a bit unsatisfactory to change the reason for the request
> so as to influence behaviour. Either the requests should ask for
> particular behaviour, or the logic for determining how to handle
> the type of request should remain in the reset logic, I would say.
I agree.
Anyway I think your patch is good as is.
Acked-by: Christian Borntraeger
On 18.07.19 15:06, Laurent Vivier wrote:
> From: Daniel P. Berrangé
>
> The SIOCGSTAMP symbol was previously defined in the
> asm-generic/sockios.h header file. QEMU sees that header
> indirectly via sys/socket.h
>
> In linux kernel commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
> the
On 18.07.19 13:06, Paolo Bonzini wrote:
> On 18/07/19 12:39, Nicholas Piggin wrote:
>> Commit 1405819637f53 ("qmp: don't emit the RESET event on wakeup from
>> S3") changed system wakeup to avoid calling qapi_event_send_reset.
>> Commit 76ed4b18debfe ("s390/ipl: fix ipl with -no-reboot")
, 9 Jul 2019 18:55:34 -0400
>>>> Collin Walling wrote:
>>>>
>>>>> On 7/8/19 9:23 AM, Christian Borntraeger wrote:
>>>>>>
>>>>>>
>>>>>> On 08.07.19 14:54, Cornelia Huck wrote:
>>>>>>&
On 16.07.19 15:04, Cornelia Huck wrote:
> On Tue, 16 Jul 2019 14:52:03 +0200
> Ilya Leoshkevich wrote:
>
>>> Am 16.07.2019 um 14:41 schrieb David Hildenbrand :
>>>
>>> How urgent is this? If this can wait, I can polish and send my series I
>>> have here
>>> instead, which also implents
>>> -
On 16.07.19 10:30, Cornelia Huck wrote:
> On Tue, 16 Jul 2019 09:25:42 +0200
> Christian Borntraeger wrote:
>
>> On 16.07.19 09:24, David Hildenbrand wrote:
>
>>> We also have
>>>
>>> sortl vs. sort
>>> vxe vs. vxeh
>>> vxe2 v
On 16.07.19 09:24, David Hildenbrand wrote:
> On 15.07.19 18:12, Christian Borntraeger wrote:
>>
>>
>> On 15.07.19 17:50, Christian Borntraeger wrote:
>>>
>>>
>>> On 15.07.19 17:02, Thomas Huth wrote:
>>>> On 15/07/2019 16.23
On 15.07.19 17:50, Christian Borntraeger wrote:
>
>
> On 15.07.19 17:02, Thomas Huth wrote:
>> On 15/07/2019 16.23, Christian Borntraeger wrote:
>>> David suggested to keep everything in sync as 4.1 is not yet released.
>>> This patch fixes the name "
On 15.07.19 17:35, Cornelia Huck wrote:
> On Mon, 15 Jul 2019 16:23:04 +0200
> Christian Borntraeger wrote:
>
>> The internal macro name VECTOR_BCD_ENH does not match the actual
>> description. Fix this.
>>
>> Signed-off-by: Christian Bor
On 15.07.19 17:02, Thomas Huth wrote:
> On 15/07/2019 16.23, Christian Borntraeger wrote:
>> David suggested to keep everything in sync as 4.1 is not yet released.
>> This patch fixes the name "vxbeh" into "vxp".
>>
>> To simplify the back
esort might not be available on all models.
Fixes: caef62430fed6e73 ("s390x/cpumodel: add gen15 defintions")
Signed-off-by: Christian Borntraeger
---
target/s390x/gen-features.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-featur
The internal macro name VECTOR_BCD_ENH does not match the actual
description. Fix this.
Signed-off-by: Christian Borntraeger
---
target/s390x/cpu_features_def.inc.h | 2 +-
target/s390x/gen-features.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/s390x
eed to be backported.
Suggested-by: David Hildenbrand
Fixes: d05be57ddc2e ("s390: cpumodel: fix description for the new vector
facility")
Fixes: 54d65de0b525 ("s390x/cpumodel: vector enhancements")
Signed-off-by: Christian Borntraeger
---
target/s390x/cpu_features_def.inc.h |
Some fallout of the gen15 cpu model. As this is new in 4.1
it is still time to fixup some aspects.
Christian Borntraeger (3):
s390x/cpumodel: remove esort from the default model
s390x/cpumodel: also change name of vxbeh
s390x/cpumodel: change internal name of vxp to make description
On 11.07.19 12:43, Juan Quintela wrote:
> The following changes since commit 6df2cdf44a82426f7a59dcb03f0dd2181ed7fdfa:
>
> Update version for v4.1.0-rc0 release (2019-07-09 17:21:53 +0100)
>
> are available in the Git repository at:
>
> https://github.com/juanquintela/qemu.git
On 11.07.19 11:24, Daniel P. Berrangé wrote:
> On Thu, Jul 11, 2019 at 10:02:01AM +0200, Christian Ehrhardt wrote:
>> On Mon, Jun 17, 2019 at 5:35 PM Laurent Vivier wrote:
>>>
>>> Le 17/06/2019 à 15:11, Daniel P. Berrangé a écrit :
The SIOCGSTAMP symbol was previously defined in the
ean.mo
> cc: fatal error: no input files
> compilation terminated.
> make: *** [rules.mak:118: recurse-clean.mo] Error 1
>
> Root cause is missing .PHONY. Fix that.
>
> Fixes: 1338a4b72659ce08eacb9de0205fe16202a22d9c
> Reported-by: Christian Borntraeger
>
This is still broken with qemu/master.
make clean/distclean no longer works on a fresh repository. As the make will
return an error
this can break any kind of scripts.
On 05.07.19 23:31, Christian Borntraeger wrote:
> This seems to break "make clean" and "make distcl
The new facility is called "Vector-Packed-Decimal-Enhancement Facility"
and not "Vector BCD enhancements facility 1". As the shortname might
have already found its way into some backports lets keep vxbeh.
Fixes: 54d65de0b525 ("s390x/cpumodel: vector enhancements&q
As this might have already sneaked into some distribution backports just fixing
the
description would be a "play-safe" variant.
-DEF_FEAT(VECTOR_BCD_ENH, "vxbeh", STFL, 152, "Vector BCD enhancements facility
1")
+DEF_FEAT(VECTOR_BCD_ENH, "vxbeh", STFL, 152,
"Vector-Packed-Decimal-Enhancement
The new facility is called "Vector-Packed-Decimal-Enhancement Facility"
and not "Vector BCD enhancements facility 1". Also fixup the short
name to "vxp" to match the Linux kernel.
Fixes: 54d65de0b525 ("s390x/cpumodel: vector enhancements")
Signed-off-by:
On 08.07.19 14:54, Cornelia Huck wrote:
> According to the comment, the bits are supposed to accumulate.
>
> Reported-by: Stefan Weil
> Fixes: 5d1abf234462 ("s390x/pci: enforce zPCI state checking")
> Signed-off-by: Cornelia Huck
This patch does not change behaviour, so it is certainly not
This seems to break "make clean" and "make distclean" in the source directory
if there was never
a configure.
qemu]$ make clean
LD recurse-clean.mo
cc: fatal error: no input files
compilation terminated.
make: *** [rules.mak:118: recurse-clean.mo] Error 1
On 02.07.19 13:34, Markus
Signed-off-by: Pierre Morel
Reviewed-by: Tony Krowiak
Reviewed-by: Christian Borntraeger
Reviewed-by: Halil Pasic
Signed-off-by: Christian Borntraeger
[rebase to newest qemu and fixup description]
---
target/s390x/cpu_features_def.inc.h | 1 +
target/s390x/cpu_models.c | 1 +
target
401 - 500 of 2509 matches
Mail list logo
