qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 7/9] memory: introduce RAM_NORESERVE and wire it up in qem


From: David Hildenbrand
Subject: Re: [PATCH v1 7/9] memory: introduce RAM_NORESERVE and wire it up in qemu_ram_mmap()
Date: Wed, 3 Mar 2021 12:37:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0

On 03.03.21 12:35, Cornelia Huck wrote:
On Tue, 2 Mar 2021 20:02:34 +0100
David Hildenbrand <david@redhat.com> wrote:

On 02.03.21 18:32, Peter Xu wrote:
On Tue, Feb 09, 2021 at 02:49:37PM +0100, David Hildenbrand wrote:
@@ -899,13 +899,17 @@ int kvm_s390_mem_op_pv(S390CPU *cpu, uint64_t offset, 
void *hostbuf,
    * to grow. We also have to use MAP parameters that avoid
    * read-only mapping of guest pages.
    */
-static void *legacy_s390_alloc(size_t size, uint64_t *align, bool shared)
+static void *legacy_s390_alloc(size_t size, uint64_t *align, bool shared,
+                               bool noreserve)
   {
       static void *mem;
if (mem) {
           /* we only support one allocation, which is enough for initial ram */
           return NULL;
+    } else if (noreserve) {
+        error_report("Skipping reservation of swap space is not supported.");
+        return NULL

Semicolon missing.

Thanks for catching that!

Regardless of that (and this patch set), can we finally get rid of
legacy_s390_alloc? We already fence off running with a kernel prior to
3.15, and KVM_CAP_S390_COW depends on ESOP -- are non-ESOP kvm hosts
still relevant? This seems to be a generation 10 feature; do we
realistically expect anyone running this on e.g. a z/VM host that
doesn't provide ESOP?

Good question - last time I asked that question (~2 years ago) I was told that such z/VM environemnts are still relevant.

--
Thanks,

David / dhildenb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]