On 11.12.20 11:51, Janosch Frank wrote:
> There's no VSIE support for a protected guest, so let's better not
> advertise it and its support facilities.
>
> Signed-off-by: Janosch Frank
Reviewed-by: Christian Borntraeger
shall we add
Fixes: 0f73c5b30b8b (
On 08.12.20 15:55, David Hildenbrand wrote:
> On 08.12.20 14:29, Christian Borntraeger wrote:
>>
>>
>> On 04.12.20 09:36, Janosch Frank wrote:
>>> There's no VSIE support for a protected guest, so let's better not
>>> advertise it and its support
On 04.12.20 09:36, Janosch Frank wrote:
> There's no VSIE support for a protected guest, so let's better not
> advertise it and its support facilities.
>
> Signed-off-by: Janosch Frank
Looks sane. Assuming that all features that depend on SIE are named
S390_FEAT_SIE_*
this should take care o
On 08.12.20 02:54, David Gibson wrote:
> On Fri, Dec 04, 2020 at 03:43:10PM +0100, Halil Pasic wrote:
>> On Fri, 4 Dec 2020 09:29:59 +0100
>> Christian Borntraeger wrote:
>>
>>> On 04.12.20 09:17, Cornelia Huck wrote:
>>>> On Fri, 4 Dec 2020 09:10:
On 04.12.20 09:17, Cornelia Huck wrote:
> On Fri, 4 Dec 2020 09:10:36 +0100
> Christian Borntraeger wrote:
>
>> On 04.12.20 06:44, David Gibson wrote:
>>> The default behaviour for virtio devices is not to use the platforms normal
>>> DMA paths, but instead
On 04.12.20 06:44, David Gibson wrote:
> The default behaviour for virtio devices is not to use the platforms normal
> DMA paths, but instead to use the fact that it's running in a hypervisor
> to directly access guest memory. That doesn't work if the guest's memory
> is protected from hypervis
On 04.12.20 06:44, David Gibson wrote:
> A number of hardware platforms are implementing mechanisms whereby the
> hypervisor does not have unfettered access to guest memory, in order
> to mitigate the security impact of a compromised hypervisor.
>
> AMD's SEV implements this with in-cpu memory
On 23.11.20 09:05, Thomas Huth wrote:
> On 23/11/2020 08.39, Christian Borntraeger wrote:
>> On 20.11.20 17:01, Eric Farman wrote:
>>> A Linux binary will have the string "S390EP" at address 0x10008,
>>> which is important in getting the guest up off th
On 20.11.20 17:01, Eric Farman wrote:
> A Linux binary will have the string "S390EP" at address 0x10008,
> which is important in getting the guest up off the ground. In the
> case of a reboot (specifically chreipl going to a new device),
> we should defer to the PSW at address zero for the new conf
On 19.11.20 13:51, Alexander Graf wrote:
>
>
> On 19.11.20 13:02, Christian Borntraeger wrote:
>>
>> On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
>>> - Background
>>>
>>> The VM Generation ID is a feature defined by Microsoft (paper:
>&g
On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
> - Background
>
> The VM Generation ID is a feature defined by Microsoft (paper:
> http://go.microsoft.com/fwlink/?LinkId=260709) and supported by
> multiple hypervisor vendors.
>
> The feature is required in virtualized environments by apps th
On 18.11.20 10:03, Thomas Huth wrote:
> Both headers, sysbus.h and module.h, are not required to compile this file.
>
> Signed-off-by: Thomas Huth
It is not a sysbus device and not a module.
Reviewed-by: Christian Borntraeger
> ---
> hw/watchdog/wdt_diag288.c | 2 --
>
On 10.11.20 11:40, Halil Pasic wrote:
> On Tue, 10 Nov 2020 09:47:51 +0100
> Christian Borntraeger wrote:
>
>>
>>
>> On 09.11.20 19:53, Halil Pasic wrote:
>>> On Mon, 9 Nov 2020 17:06:16 +0100
>>> Cornelia Huck wrote:
>>>
>&
On 09.11.20 19:53, Halil Pasic wrote:
> On Mon, 9 Nov 2020 17:06:16 +0100
> Cornelia Huck wrote:
>
>>> @@ -20,6 +21,11 @@ static void virtio_ccw_blk_realize(VirtioCcwDevice
>>> *ccw_dev, Error **errp)
>>> {
>>> VirtIOBlkCcw *dev = VIRTIO_BLK_CCW(ccw_dev);
>>> DeviceState *vdev = DE
t) this is hardly a surprise.
>
> As for non-secure VMs the extra queues shouldn't hurt too much.
In fact we have also seen improvments for multiqueues for non secure guests
as one virtqueue seems to have a hard capping in terms of bandwidth that can
be smaller than newer storage de
On 03.11.20 13:32, Thomas Huth wrote:
> On 30/10/2020 13.28, Christian Borntraeger wrote:
>> From: "Jason J. Herne"
>>
>> The architecture states that the iplb location is only written to low
>> core for list directed ipl and not for traditional ccw ipl. If
On 30.10.20 13:28, Christian Borntraeger wrote:
> From: "Jason J. Herne"
>
> The architecture states that the iplb location is only written to low
> core for list directed ipl and not for traditional ccw ipl. If we don't
> skip this then operating systems that
> that hopefully makes this iotest work on both x86 and s390.
>
> Best regards,
> Maxim Levitsky
>
> Maxim Levitsky (2):
> iotests: add filter_qmp_virtio_scsi function
> iotests: rewrite iotest 240 in python
Both patches on s390x
Tested-by: Christian Borntraeger
write the iplb pointer for network boot as it might
overwrite content that we got via network.
Signed-off-by: Jason J. Herne
Fixes: 9bfc04f9ef68 ("pc-bios: s390x: Save iplb location in lowcore")
Signed-off-by: Christian Borntraeger
---
pc-bios/s390-ccw/main.c | 4 +++-
1 file changed, 3
On 19.10.20 18:37, Maxim Levitsky wrote:
> The recent changes that brought RCU delayed device deletion,
> broke few tests and this test breakage went unnoticed.
>
> Fix this test by rewriting it in python
> (which allows to wait for DEVICE_DELETED events before continuing).
While this is now fine
On 26.10.20 15:30, Paolo Bonzini wrote:
> Cc: Thomas Huth
> Signed-off-by: Paolo Bonzini
> ---
> hw/s390x/ipl.c | 8 ++--
> hw/s390x/s390-virtio-ccw.c | 3 ++-
> 2 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
> index 3d2652d7
s390: guest support for diagnose 0x318")
I prefer v1 as it is more obvious what happens, but this looks fine as well
and as David prefers this let us go with this one.
Reviewed-by: Christian Borntraeger
> ---
> target/s390x/cpu_features.c | 5 +
> target/s390x/cpu_features.h | 4 ++
;> Reported-by: Marc Hartmayer
>> Reviewed-by: Christian Borntraeger
>> Fixes: fabdada935 ("s390: guest support for diagnose 0x318")
>> Tested-by: Marc Hartmayer
>> ---
>> hw/s390x/sclp.c| 10 ++
>> target/s390x/kvm.c | 3 +--
>> 2
On 17.10.20 20:09, Alexander Graf wrote:
> Hi Jason,
>
> On 17.10.20 15:24, Jason A. Donenfeld wrote:
>>
>> After discussing this offline with Jann a bit, I have a few general
>> comments on the design of this.
>>
>> First, the UUID communicated by the hypervisor should be consumed by
>> the ke
On 15.10.20 15:32, Christian Borntraeger wrote:
>
>
> On 15.10.20 15:16, Matthew Rosato wrote:
>> Currently, a subsystem reset event leaves PCI devices enabled, causing
>> issues post-reset in the guest (an example would be after a kexec). These
>> devices need to
y re-enabled afterwards. Add the S390 PCI host bridge to the list
> of qdevs to be reset during subsystem reset.
>
> Signed-off-by: Matthew Rosato
> Reviewed-by: Eric Farman
Makese sense.
Acked-by: Christian Borntraeger
> ---
> hw/s390x/s390-virtio-ccw.c | 1 +
> 1 file changed,
On 06.10.20 20:31, Thomas Huth wrote:
> Hi Peter,
>
> the following changes since commit d7c5b788295426c1ef48a9ffc3432c51220f69ba:
>
> Merge remote-tracking branch
> 'remotes/stefanha-gitlab/tags/block-pull-request' into staging (2020-10-06
> 12:15:59 +0100)
>
> are available in the Git
On 30.09.20 19:19, Eric Blake wrote:
> On 9/30/20 10:58 AM, Christian Borntraeger wrote:
>> gcc 10 from Fedora 32 gives me:
>>
>> Compiling C object libblock.fa.p/nbd_server.c.o
>> ../nbd/server.c: In function ‘nbd_co_client_start’:
>> ../nbd/server.c:625
On 30.09.20 18:36, Fam Zheng wrote:
> On Wed, 2020-09-30 at 17:58 +0200, Christian Borntraeger wrote:
>> Fedora 32 gcc 10 seems to give false positives:
>>
>> Compiling C object libblock.fa.p/block_vmdk.c.o
>> ../block/vmdk.c: In function ‘vmdk_parse_extents’:
>
On 30.09.20 18:27, Dr. David Alan Gilbert wrote:
> * Christian Borntraeger (borntrae...@de.ibm.com) wrote:
>> make: *** [Makefile:121: config-host.mak] Error 1
>> [cborntra@m83lp52 qemu]$ make -C build/
>> make: Entering directory '/home/cborntra/REPOS/qemu/build
On 01.10.20 13:20, Peter Maydell wrote:
> On Thu, 1 Oct 2020 at 11:35, Markus Armbruster wrote:
>>
>> We deprecated "?" more than eight years ago. We didn't have a
>> deprecation process back then, but we did purge "?" from the
>> documentation and from help texts. Can we finally drop it?
>
I might be wrong and some of these warnings could be correct, so some
review from the subject matter experts would be good.
Christian Borntraeger (4):
vmdk: fix maybe uninitialized warnings
nbd: silence maybe-uninitialized warnings
qemu-io-cmds: avoid gcc 10 warning
virtiofsd: avoid false
value.
Signed-off-by: Christian Borntraeger
---
block/vmdk.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 8ec62c7ab798..a00dc00eb47a 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -595,7 +595,7 @@ static int vmdk_open_vmfs_sparse
namelen;
| ^~~
cc1: all warnings being treated as errors
As I cannot see how this can happen, let uns silence the warning.
Signed-off-by: Christian Borntraeger
---
nbd/server.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/nbd/server.c b/nbd/server.c
as errors
make: *** [Makefile.ninja:1438: tools/virtiofsd/virtiofsd.p/passthrough_ll.c.o]
Error 1
make: Leaving directory '/home/cborntra/REPOS/
as far as I can see this can not happen. Let us silence the warning by
giving fd a default value.
Signed-off-by: Christian Borntraeger
---
- 1, __fmt, __va_arg_pack
());
| ^~~
cc1: all warnings being treated as errors
Let us check for null.
Signed-off-by: Christian Borntraeger
---
qemu-io-cmds.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
On 28.09.20 14:27, David Hildenbrand wrote:
> Let's avoid confusion with the "Miscellaneous-Instruction-Extensions
> Facility 1"
>
> Suggested-by: Thomas Huth
> Cc: Christian Borntraeger
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/cpu_fea
On 24.09.20 12:48, Daniel P. Berrangé wrote:
> On Thu, Sep 24, 2020 at 12:35:06PM +0200, Christian Borntraeger wrote:
>> Gerd,
>>
>> with current master build via a slightly fixed up fedora spec file I do get
>> a crash in virtio-gpu
>> when libvirt queries
Gerd,
with current master build via a slightly fixed up fedora spec file I do get a
crash in virtio-gpu
when libvirt queries the qemu.
I can trigger that also via command line
$ /usr/bin/qemu-system-s390x -device virtio-gpu-pci,help
qemu-system-s390x: -device virtio-gpu-pci,help: missing object
On 16.07.20 14:02, Cornelia Huck wrote:
> On Wed, 15 Jul 2020 12:26:20 -0400
> Collin Walling wrote:
>
>> On 7/15/20 12:04 PM, Cornelia Huck wrote:
>>> On Wed, 15 Jul 2020 11:36:35 -0400
>>> Collin Walling wrote:
>>>
Polite ping. Patches have been sitting on the list for a few weeks n
CCing qemu-s390x.
On 01.09.20 17:00, Marc Hartmayer wrote:
> This patch series is about enabling virtio-fs on s390x. For that we need
> + some shim code (first patch), and we need
> + libvhost-user to deal with virtio endiannes for non-legacy virtio
>devices as mandated by the spec.
>
> Ho
On 27.08.20 11:31, Janosch Frank wrote:
> Let's setup a PGM PSW, so we won't load 0s when a program exception
> happens. Instead we'll load a disabled wait PSW.
Makes sense
Reviewed-by: Christian Borntraeger
>
> Signed-off-by: Janosch Frank
> ---
> pc-b
/pc_piix.c | 14 +-
> hw/i386/pc_q35.c | 13 -
> hw/ppc/spapr.c | 15 +--
> hw/s390x/s390-virtio-ccw.c | 14 +++++-
Acked-by: Christian Borntraeger
> include/hw/boards.h| 3 +++
> include/hw/i386/pc.
On 27.07.20 11:42, Cornelia Huck wrote:
> On Fri, 24 Jul 2020 16:37:45 +0200
> David Hildenbrand wrote:
>
>> Let's generalize, abstacting the virtio bits. diag500 is now a generic
>> hypercall to handle QEMU/KVM specific things. Explicitly specify all
>> already defined subcodes, including leg
eed to dynamically register diag500 handlers. Move the two existing
>
> Hm, do we want to make certain subcodes available only if certain code
> has been configured? If yes, it might make sense to keep the mechanism.
>
I think the registration really makes the code hard to read. So
On 23.07.20 17:05, Cornelia Huck wrote:
> On Tue, 21 Jul 2020 14:29:29 +0200
> Christian Borntraeger wrote:
>
>> On 21.07.20 14:25, Janosch Frank wrote:
>>> On 7/21/20 12:32 PM, Christian Borntraeger wrote:
>>>> Right now -no-reboot does prevent
On 22.07.20 09:24, Janosch Frank wrote:
> On 7/22/20 8:43 AM, Christian Borntraeger wrote:
>>
>>
>> On 15.07.20 16:08, Janosch Frank wrote:
>>> Normally they don't need to be set up before waiting for an interrupt
>>> but are set up on boot. The BIOS
On 22.07.20 09:30, Janosch Frank wrote:
> On 7/22/20 8:50 AM, Christian Borntraeger wrote:
>>
>>
>> On 15.07.20 11:40, Janosch Frank wrote:
>>> The two main types of zipl component entries are execute and
>>> load/data. The last member of the component en
On 15.07.20 11:40, Janosch Frank wrote:
> The two main types of zipl component entries are execute and
> load/data. The last member of the component entry struct therefore
> denotes either a PSW or an address. Let's make this a bit more clear
> by introducing a union and cleaning up the code tha
On 21.07.20 09:05, Thomas Huth wrote:
> On 15/07/2020 11.40, Janosch Frank wrote:
[..]
>> #ifndef S390_ARCH_H
>> #define S390_ARCH_H
>>
>> +/* s390 psw bit masks */
>> +#define PSW_MASK_EXT0x0100UL
>> +#define PSW_MASK_IOINT 0x0200ULL
>> +#define PSW_MASK
On 15.07.20 16:08, Janosch Frank wrote:
> Normally they don't need to be set up before waiting for an interrupt
> but are set up on boot. The BIOS however might overwrite the lowcore
> (and hence the PSWs) when loading a blob into memory and therefore
> needs to set up those PSWs more often.
No
On 17.07.20 17:13, Thomas Huth wrote:
> On 15/07/2020 11.40, Janosch Frank wrote:
>> jump_to_IPL_code takes a 64 bit address, masks it with the short psw
>> address mask and later branches to it using a full 64 bit register.
>>
>> * As the masking is not necessary, let's remove it
>> * Without t
On 21.07.20 14:25, Janosch Frank wrote:
> On 7/21/20 12:32 PM, Christian Borntraeger wrote:
>> Right now -no-reboot does prevent secure execution guests from running.
>
> s/-no-reboot/--no-reboot/
Actually qemu --help gives the parameters with just one "-"
Not sure
eal reboot/reset must happen in-between.
So function code 10 is more or less a state transition reset, but not a
"standard" reset or reboot.
Fixes: 4d226deafc44 ("s390x: protvirt: Support unpack facility")
Signed-off-by: Christian Borntraeger
---
hw/s390x/ipl.c | 3 ++-
1 fil
On 15.07.20 15:13, Janosch Frank wrote:
> On 7/15/20 11:40 AM, Janosch Frank wrote:
>> Absolutely no need to set them up every time before we enable our
>> interrupt masks.
>>
>> Signed-off-by: Janosch Frank
>
> So, this one doesn't seem to be a great idea as a kernel loaded to 0x0
> will over
On 13.07.20 14:11, Cornelia Huck wrote:
> On Mon, 13 Jul 2020 13:54:41 +0200
> Christian Borntraeger wrote:
>
>> On 10.07.20 10:32, David Hildenbrand wrote:
>>
>>>>> --- a/target/s390x/misc_helper.c
>>>>> +++ b/target/s390x/misc_h
On 10.07.20 10:32, David Hildenbrand wrote:
>>> --- a/target/s390x/misc_helper.c
>>> +++ b/target/s390x/misc_helper.c
>>> @@ -116,6 +116,12 @@ void HELPER(diag)(CPUS390XState *env, uint32_t r1,
>>> uint32_t r3, uint32_t num)
>>> uint64_t r;
>>>
>>> switch (num) {
>>> +case 0x26
On 13.07.20 12:27, David Hildenbrand wrote:
>
>
>> Am 13.07.2020 um 11:12 schrieb Heiko Carstens :
>>
>> On Fri, Jul 10, 2020 at 05:24:07PM +0200, David Hildenbrand wrote:
On 10.07.20 17:18, Heiko Carstens wrote:
On Fri, Jul 10, 2020 at 02:12:33PM +0200, David Hildenbrand wrote:
>>
On 08.07.20 20:51, David Hildenbrand wrote:
> Let's implement the "storage configuration" part of diag260. This diag
> is found under z/VM, to indicate usable chunks of memory tot he guest OS.
> As I don't have access to documentation, I have no clue what the actual
> error cases are, and which o
On 04.07.20 20:34, Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2020 at 06:50:34AM +0200, Halil Pasic wrote:
>> The atomic_cmpxchg() loop is broken because we occasionally end up with
>> old and _old having different values (a legit compiler can generate code
>> that accessed *ind_addr again to p
ract machine for
> accesses to *ind_addr. Let us also rewrite the loop so, we that the
> new old is used to compute the new desired value if the xchg part
> is not performed.
>
> Signed-off-by: Halil Pasic
> Fixes: 8cba80c3a0 ("s390: Add PCI bus support")
> R
ract machine for
> accesses to *ind_addr. Let us also rewrite the loop so, we that the
> new old is used to compute the new desired value if the xchg part
> is not performed.
>
> Signed-off-by: Halil Pasic
> Reported-by: Andre Wild
> Fixes: 7e7494627f ("s390x/virtio-ccw:
On 01.07.20 14:01, Cornelia Huck wrote:
> On Tue, 16 Jun 2020 06:50:33 +0200
> Halil Pasic wrote:
>
>> The story short: compiler can generate code that does two
>> distinct fetches of *ind_addr for old and _old. If that happens we can
>> not figure out if we had the desired xchg or not.
>>
>>
On 19.06.20 00:22, Collin Walling wrote:
> Rework the SCLP boundary check to account for different SCLP commands
> (eventually) allowing different boundary sizes.
>
> Move the length check code into a separate function, and introduce a
> new function to determine the length of the read SCP data
On 19.06.20 12:50, Janosch Frank wrote:
> On 6/19/20 12:22 AM, Collin Walling wrote:
>> Rework the SCLP boundary check to account for different SCLP commands
>> (eventually) allowing different boundary sizes.
>>
>> Move the length check code into a separate function, and introduce a
>> new funct
On 19.06.20 04:05, David Gibson wrote:
> A number of hardware platforms are implementing mechanisms whereby the
> hypervisor does not have unfettered access to guest memory, in order
> to mitigate the security impact of a compromised hypervisor.
>
> AMD's SEV implements this with in-cpu memory enc
wrong Person on to, I wanted to send this to Tony.
On 17.06.20 18:06, Christian Borntraeger wrote:
> device_del requires an id and not a sysfsfile.
>
> Signed-off-by: Christian Borntraeger
> ---
> docs/system/s390x/vfio-ap.rst | 8
> 1 file changed, 4 insertio
device_del requires an id and not a sysfsfile.
Signed-off-by: Christian Borntraeger
---
docs/system/s390x/vfio-ap.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/system/s390x/vfio-ap.rst b/docs/system/s390x/vfio-ap.rst
index 3cd84179a2df..f441df69edde 100644
On 16.06.20 08:33, Cornelia Huck wrote:
> On Tue, 16 Jun 2020 07:58:53 +0200
> Christian Borntraeger wrote:
>
>> On 16.06.20 06:50, Halil Pasic wrote:
>>> The atomic_cmpxchg() loop is broken because we occasionally end up with
>>> old and _old having diffe
On 16.06.20 06:50, Halil Pasic wrote:
> The atomic_cmpxchg() loop is broken because we occasionally end up with
> old and _old having different values (a legit compiler can generate code
> that accessed *ind_addr again to pick up a value for _old instead of
> using the value of old that was alre
On 27.05.20 09:49, Janosch Frank wrote:
> If we have a lowcore struct that has members for offsets that we want
> to touch, why not use it?
>
> Signed-off-by: Janosch Frank
> Reviewed-by: David Hildenbrand
> ---
> pc-bios/s390-ccw/cio.h | 17 +++--
> pc-bios/s390-ccw/main.c | 8
On 27.05.20 09:49, Janosch Frank wrote:
> Let's consolidate timing related functions into one header.
>
> Signed-off-by: Janosch Frank
> ---
> pc-bios/s390-ccw/menu.c| 1 +
> pc-bios/s390-ccw/netmain.c | 15 +++
> pc-bios/s390-ccw/s390-ccw.h| 2 --
> pc-bios/s390
d sleep(unsigned int seconds)
> +{
> +ulong target = get_time_seconds() + seconds;
> +
> +while (get_time_seconds() < target) {
> +yield();
> +}
This actually asks for a future cleanup patch to replace the busy wait with a
sleeping wait.
Anyway,
Reviewed-by: C
CW_CMD_BASIC_SENSE;
> -senseCcw.cda = ptr2u32(sense_data);
> - senseCcw.count = data_size;
> -
here it is fine, due to the lack of flags.
Was this actually a bug before that senseCcw.flags was
not zeroed out?
[...]
Other than that
Reviewed-by: Christian Borntraeger
On 02.05.20 07:15, Markus Armbruster wrote:
> Christian Borntraeger writes:
>
>> On 29.04.20 10:54, Christian Borntraeger wrote:
>>>
>>>
>>> On 28.04.20 19:13, David Hildenbrand wrote:
>>>> On 28.04.20 18:34, Markus Armbruster wrote:
>&g
On 29.04.20 10:54, Christian Borntraeger wrote:
>
>
> On 28.04.20 19:13, David Hildenbrand wrote:
>> On 28.04.20 18:34, Markus Armbruster wrote:
>>> Both s390_features[S390_FEAT_PCC_CMAC_AES_256].name and
>>> s390_features[S390_FEAT_PCC_CMAC_EAES_256].name
On 28.04.20 19:13, David Hildenbrand wrote:
> On 28.04.20 18:34, Markus Armbruster wrote:
>> Both s390_features[S390_FEAT_PCC_CMAC_AES_256].name and
>> s390_features[S390_FEAT_PCC_CMAC_EAES_256].name is
>> "pcc-cmac-eaes-256". The former is obviously a pasto.
>>
>> Impact:
>>
>> * s390_feat_bit
We need some little help in the code to reduce the valgrind noise.
This patch does this with some designated initializers for the cpu
model features and subfunctions.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Christian Borntraeger
---
target/s390x/kvm.c | 4 ++--
1 file changed, 2
On 29.04.20 09:00, Philippe Mathieu-Daudé wrote:
> Hi Christian,
>
> On 4/28/20 8:31 PM, Christian Borntraeger wrote:
>> We need some little help in the code to reduce the valgrind noise.
>> - some designated initializers for the cpu model features and subfunctions
&g
We need some little help in the code to reduce the valgrind noise.
- some designated initializers for the cpu model features and subfunctions
- mark memory as defined for sida memory reads
Signed-off-by: Christian Borntraeger
---
target/s390x/kvm.c | 15 +--
1 file changed, 13
ddress space include
3. mention the rename in the patch description
Christian Borntraeger (1):
s390x/s390-virtio-ccw: Fix build on systems without KVM
hw/s390x/ipl.h | 1 +
hw/s390x/pv.c | 11 +++
hw/s390x/s390-virtio-ccw.c | 12 +---
include/hw/s390
ry.
Fixes: 49fc3220175e ("s390x: protvirt: Support unpack facility")
Reported-by: Bruce Rogers
Signed-off-by: Christian Borntraeger
---
hw/s390x/ipl.h | 1 +
hw/s390x/pv.c | 11 +++
hw/s390x/s390-virtio-ccw.c | 12 +---
include/hw/s390x/pv.h | 3 +++
On 06.04.20 11:32, David Hildenbrand wrote:
> On 06.04.20 11:29, Christian Borntraeger wrote:
>>
>>
>> On 06.04.20 11:07, David Hildenbrand wrote:
>>>
>>>> static inline bool s390_is_pv(void)
>>>> @@ -41,6 +42,7 @@ int s390_pv_unp
On 06.04.20 11:07, David Hildenbrand wrote:
>
>> static inline bool s390_is_pv(void)
>> @@ -41,6 +42,7 @@ int s390_pv_unpack(uint64_t addr, uint64_t size, uint64_t
>> tweak);
>> void s390_pv_perf_clear_reset(void);
>> int s390_pv_verify(void);
>> void s390_pv_unshare(void);
>> +void s390_m
On 06.04.20 11:04, Cornelia Huck wrote:
> On Mon, 6 Apr 2020 03:59:31 -0400
> Christian Borntraeger wrote:
>
>> linux/kvm.h is not available on all platforms. Let us move
>> s390_machine_inject_pv_error into pv.c as it uses KVM structures.
>>
>> Fixes: 49fc32
Bruce Rogers reported that hw/s390/ipl.c does not compile on RISC-V due
to missing KVM headers.
Instead of ifdef we should probably move the problematic function into
pv.c
Christian Borntraeger (1):
s390x/s390-virtio-ccw: Fix build on systems without KVM
hw/s390x/ipl.h | 1 +
hw
linux/kvm.h is not available on all platforms. Let us move
s390_machine_inject_pv_error into pv.c as it uses KVM structures.
Fixes: 49fc3220175e ("s390x: protvirt: Support unpack facility")
Reported-by: Bruce Rogers
Signed-off-by: Christian Borntraeger
---
hw/s390x/ipl.h
On 02.04.20 14:09, Christian Borntraeger wrote:
>
>
> On 02.04.20 14:05, Igor Mammedov wrote:
>> On Thu, 2 Apr 2020 13:42:22 +0200
>> Christian Borntraeger wrote:
>>
>>> On 02.04.20 13:39, Igor Mammedov wrote:
>>> [...]
>>>>
On 02.04.20 14:05, Igor Mammedov wrote:
> On Thu, 2 Apr 2020 13:42:22 +0200
> Christian Borntraeger wrote:
>
>> On 02.04.20 13:39, Igor Mammedov wrote:
>> [...]
>>>>>
>>>>>> +"
On 02.04.20 13:39, Igor Mammedov wrote:
[...]
>>>
+"MB to match machine restrictions. Consider updating "
+"the guest definition.i\n", sz / MiB, newsz / MiB);
>>>
>>> also it might be better to use size_to_str() to format numbers
>
On 02.04.20 13:25, Cornelia Huck wrote:
>>
>> Is the the only thing that blocks this? I would rather try to get this fixed
>> before rc2.
>>
>
> I now have
>
> if (sz != newsz) {
>
> qemu_printf("Ram size %" PRIu64 "MB wa
On 02.04.20 12:27, Cornelia Huck wrote:
>> We could simply do an u64 cast?
>
> Not sure if we might end up with "cast to integer of different length"
> values on some platforms (that I unfortunately don't have around to
> test). I hate that stuff.
That kind of message should NEVER happen. the
On 02.04.20 11:27, Cornelia Huck wrote:
> On Wed, 1 Apr 2020 18:34:56 +0200
> Igor Mammedov wrote:
>
>> On Wed, 1 Apr 2020 08:37:54 -0400
>> Christian Borntraeger wrote:
>
>>> +static ram_addr_t s390_fixup_ram_size(ram_addr_t sz)
>>> +{
>>&
On 02.04.20 11:22, Cornelia Huck wrote:
> On Wed, 1 Apr 2020 15:14:12 +0200
> David Hildenbrand wrote:
>
>> On 01.04.20 14:37, Christian Borntraeger wrote:
>
>>> +static ram_addr_t s390_fixup_ram_size(ram_addr_t sz)
>>> +{
>>> +/* same logi
On 01.04.20 14:37, Christian Borntraeger wrote:
> +if (sz != newsz) {
> +qemu_printf("Ram size %" PRIu64 "MB was fixed up to %" PRIu64
> +"MB to match machine restrictions. Consider updating "
> +&
d storage attributes for hotplugged memory
will have to be migrated per RAM block in the future).
Fixes: 3a12fc61af5c ("390x/s390-virtio-ccw: use memdev for RAM")
Reported-by: Lukáš Doktor
Cc: Igor Mammedov
Cc: Dr. David Alan Gilbert
Signed-off-by: David Hildenbrand
Signed-off-by: Ch
On 01.04.20 10:58, David Hildenbrand wrote:
> On 01.04.20 10:50, Christian Borntraeger wrote:
>> Older QEMU versions did fixup the ram size to match what can be reported
>> via sclp. We need to mimic this behaviour for machine types 4.2 and
>> older to not fail on inbound
On 01.04.20 12:13, Cornelia Huck wrote:
> On Wed, 1 Apr 2020 04:50:14 -0400
> Christian Borntraeger wrote:
>
>> Older QEMU versions did fixup the ram size to match what can be reported
>> via sclp. We need to mimic this behaviour for machine types 4.2 and
>> o
B.
Fixes: 3a12fc61af5c ("390x/s390-virtio-ccw: use memdev for RAM")
Reported-by: Lukáš Doktor
Cc: Igor Mammedov
Cc: Dr. David Alan Gilbert
Signed-off-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
---
hw/s390x/s390-skeys.c| 2 +-
hw/s390x/s390-stattrib-kvm.c | 4
On 31.03.20 23:49, Igor Mammedov wrote:
> On Tue, 31 Mar 2020 11:35:54 -0400
> Christian Borntraeger wrote:
>
>> compat machines did fixup the ram size to match what can be reported via
>> sclp. We need to mimic those for machines 4.2 and older to not fail on
>&g
201 - 300 of 2519 matches
Mail list logo
