qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: "Jason J . Herne" <jjherne@linux.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-s390x@nongnu.org, Claudio Imbrenda <imbrenda@linux.ibm.com>
Subject: Re: [PATCH v1 09/12] hw/s390x/s390-skeys: use memory mapping to detect which storage keys to migrate
Date: Fri, 6 Aug 2021 10:47:04 +0200	[thread overview]
Message-ID: <9f614da7-e1c6-b2c9-04f1-ee8ad8c60b5e@redhat.com> (raw)
In-Reply-To: <20210805152804.100333-10-david@redhat.com>

On 05/08/2021 17.28, David Hildenbrand wrote:
> Let's use the guest_phys_blocks API to get physical memory regions
> that are well defined inside our physical address space and migrate the
> storage keys of these.
> 
> This is a prepearation for having memory besides initial ram defined in

s/prepearation/preparation/

> the guest physical address space, for example, via memory devices. We
> get rid of the ms->ram_size dependency.
> 
> Please note that we will usually have very little (--> 1) physical
> ranges. With virtio-mem might have significantly more ranges in the
> future. If that turns out to be a problem (e.g., total memory
> footprint of the list), we could look into a memory mapping
> API that avoids creation of a list and instead triggers a callback for
> each range.
> 
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>   hw/s390x/s390-skeys.c | 70 ++++++++++++++++++++++++++-----------------
>   1 file changed, 43 insertions(+), 27 deletions(-)

Reviewed-by: Thomas Huth <thuth@redhat.com>



  reply	other threads:[~2021-08-06  8:47 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 15:27 [PATCH v1 00/12] s390x: skey related fixes, cleanups, and memory device preparations David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 01/12] s390x/tcg: wrap address for RRBE David Hildenbrand
2021-08-06  5:39   ` Thomas Huth
2021-08-05 15:27 ` [PATCH v1 02/12] s390x/tcg: fix ignoring bit 63 when setting the storage key in SSKE David Hildenbrand
2021-08-06  6:19   ` Thomas Huth
2021-08-06  6:25     ` Thomas Huth
2021-08-06  6:31       ` David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 03/12] s390x/tcg: convert real to absolute address for RRBE, SSKE and ISKE David Hildenbrand
2021-08-06  6:50   ` Thomas Huth
2021-08-06  6:52     ` David Hildenbrand
2021-08-06  7:11       ` Thomas Huth
2021-08-06  7:17         ` David Hildenbrand
2021-08-06 11:25           ` Cornelia Huck
2021-08-06 11:32             ` David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 04/12] s390x/tcg: check for addressing exceptions for " David Hildenbrand
2021-08-05 17:33   ` David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 05/12] s390x/mmu_helper: no need to pass access type to mmu_translate_asce() David Hildenbrand
2021-08-06  7:30   ` Thomas Huth
2021-08-06  7:34     ` David Hildenbrand
2021-08-06  7:36       ` Thomas Huth
2021-08-06  7:36         ` David Hildenbrand
2021-08-05 15:27 ` [PATCH v1 06/12] s390x/mmu_helper: fixup mmu_translate() documentation David Hildenbrand
2021-08-06  7:32   ` Thomas Huth
2021-08-05 15:27 ` [PATCH v1 07/12] s390x/mmu_helper: move address validation into mmu_translate*() David Hildenbrand
2021-08-06  8:18   ` Thomas Huth
2021-08-06  8:20     ` David Hildenbrand
2021-08-06  8:22       ` Thomas Huth
2021-08-06  8:23         ` David Hildenbrand
2021-08-06  8:24           ` Thomas Huth
2021-08-06  8:20   ` Thomas Huth
2021-08-05 15:28 ` [PATCH v1 08/12] s390x/mmu_helper: avoid setting the storage key if nothing changed David Hildenbrand
2021-08-06  8:24   ` Thomas Huth
2021-08-05 15:28 ` [PATCH v1 09/12] hw/s390x/s390-skeys: use memory mapping to detect which storage keys to migrate David Hildenbrand
2021-08-06  8:47   ` Thomas Huth [this message]
2021-08-05 15:28 ` [PATCH v1 10/12] hw/s390x/s390-skeys: use memory mapping to detect which storage keys to dump David Hildenbrand
2021-08-06  8:51   ` Thomas Huth
2021-08-05 15:28 ` [PATCH v1 11/12] hw/s390x/s390-skeys: check if an address is valid before dumping the key David Hildenbrand
2021-08-06  8:53   ` Thomas Huth
2021-08-06  8:54     ` David Hildenbrand
2021-08-05 15:28 ` [PATCH v1 12/12] hw/s390x/s390-skeys: lazy storage key enablement under TCG David Hildenbrand
2021-08-06  9:42   ` Thomas Huth
2021-08-06 13:18     ` David Hildenbrand
2021-08-06 13:52       ` Thomas Huth
2021-08-11  8:43         ` David Hildenbrand
2021-08-06 14:13       ` Cornelia Huck
2021-08-06 14:17         ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f614da7-e1c6-b2c9-04f1-ee8ad8c60b5e@redhat.com \
    --to=thuth@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=pasic@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).