qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Getting rid of phys_mem_set_alloc


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] Getting rid of phys_mem_set_alloc
Date: Mon, 8 Jan 2018 20:53:31 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 08/01/2018 18:05, Cornelia Huck wrote:
On Sun,  7 Jan 2018 14:32:21 +0200
Marcel Apfelbaum <address@hidden> wrote:

Looking at the churn below...


Hi Cornelia,
Thanks for looking at the patch.

diff --git a/exec.c b/exec.c
index 4722e521d4..247f8bd0c0 100644
--- a/exec.c
+++ b/exec.c
@@ -1278,7 +1278,7 @@ static int subpage_register (subpage_t *mmio, uint32_t 
start, uint32_t end,
                               uint16_t section);
  static subpage_t *subpage_init(FlatView *fv, hwaddr base);
-static void *(*phys_mem_alloc)(size_t size, uint64_t *align) =
+static void *(*phys_mem_alloc)(size_t size, uint64_t *align, bool shared) =
                                 qemu_anon_ram_alloc;
/*
@@ -1286,7 +1286,7 @@ static void *(*phys_mem_alloc)(size_t size, uint64_t 
*align) =
   * Accelerators with unusual needs may need this.  Hopefully, we can
   * get rid of it eventually.
   */
-void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align))
+void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align, bool shared))
  {
      phys_mem_alloc = alloc;
  }

diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index bbf12a1723..85002ac49a 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -248,7 +248,7 @@ int kvm_on_sigbus(int code, void *addr);
/* interface with exec.c */ -void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align));
+void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align, bool shared));
/* internal API */

diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 9b8b59f2a2..6c0fc2f89c 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -144,7 +144,7 @@ static int cap_gs;
static int active_cmma; -static void *legacy_s390_alloc(size_t size, uint64_t *align);
+static void *legacy_s390_alloc(size_t size, uint64_t *align, bool shared);
static int kvm_s390_query_mem_limit(uint64_t *memory_limit)
  {
@@ -743,7 +743,7 @@ int kvm_s390_mem_op(S390CPU *cpu, vaddr addr, uint8_t ar, 
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)
+static void *legacy_s390_alloc(size_t size, uint64_t *align, bool shared)
  {
      void *mem;

...I'm wondering whether we have any chance to get rid of this in the
future?


As far as I know, we don't usually stop supporting very ancient archs/systems;
if there is at least a system needing the support (e.g. s390x/kvm), it will
probably remain in the code. But is s390's maintainers decision, of course.

Thanks,
Marcel

s390x/kvm is the only user:

     if (!kvm_check_extension(s, KVM_CAP_S390_GMAP)
         || !kvm_check_extension(s, KVM_CAP_S390_COW)) {
         phys_mem_set_alloc(legacy_s390_alloc);
     }

In practice, this means depending on ESOP in the host. Are there still
any machines/hypervisors without ESOP that we can reasonably expect
people to run kvm on?





reply via email to

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