kvmarm.lists.cs.columbia.edu archive mirror
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>
Cc: kvm@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Raphael Gault <raphael.gault@arm.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	kvmarm@lists.cs.columbia.edu
Subject: [PATCH kvmtool v4 5/5] cfi-flash: Add support for mapping flash into guest
Date: Thu, 23 Apr 2020 18:38:44 +0100	[thread overview]
Message-ID: <20200423173844.24220-6-andre.przywara@arm.com> (raw)
In-Reply-To: <20200423173844.24220-1-andre.przywara@arm.com>

At the moment we trap *every* access to the flash memory, even when we
are in array read mode (which just directly copies from the storage
array to the guest).
To improve performance, allow cacheable mappings and to avoid fatal traps
on unsupported instructions (on ARM), export a read-only memslot to the
guest when the flash is in read-array mode. A guest does not need to
trap on read accesses then.
A write command (which always traps) will revoke this mapping if the
read mode changes.

This reduces the number of read traps from more than 800,000 to a few
hundreds when booting into the UEFI shell.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 hw/cfi_flash.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/hw/cfi_flash.c b/hw/cfi_flash.c
index 3c76c04a..7faecdfb 100644
--- a/hw/cfi_flash.c
+++ b/hw/cfi_flash.c
@@ -8,6 +8,7 @@
 
 #include "kvm/kvm.h"
 #include "kvm/kvm-arch.h"
+#include "kvm/kvm-cpu.h"
 #include "kvm/devices.h"
 #include "kvm/fdt.h"
 #include "kvm/mutex.h"
@@ -139,6 +140,7 @@ struct cfi_flash_device {
 	enum cfi_flash_state	state;
 	enum cfi_read_mode	read_mode;
 	u8			sr;
+	bool			is_mapped;
 };
 
 static int nr_erase_blocks(struct cfi_flash_device *sfdev)
@@ -437,6 +439,43 @@ static void cfi_flash_write(struct cfi_flash_device *sfdev, u16 command,
 	}
 }
 
+/*
+ * If we are in ARRAY_READ mode, we can map the flash array directly
+ * into the guest, just as read-only. This greatly improves read
+ * performance, and avoids problems with exits due to accesses from
+ * load instructions without syndrome information (on ARM).
+ * Also it could allow code to be executed XIP in there.
+ */
+static int map_flash_memory(struct kvm *kvm, struct cfi_flash_device *sfdev)
+{
+	int ret;
+
+	ret = kvm__register_mem(kvm, sfdev->base_addr, sfdev->size,
+				sfdev->flash_memory,
+				KVM_MEM_TYPE_RAM | KVM_MEM_TYPE_READONLY);
+	if (!ret)
+		sfdev->is_mapped = true;
+
+	return ret;
+}
+
+/*
+ * Any write access changing the read mode would need to bring us back to
+ * "trap everything", as the CFI query read need proper handholding.
+ */
+static int unmap_flash_memory(struct kvm *kvm, struct cfi_flash_device *sfdev)
+{
+	int ret;
+
+	ret = kvm__destroy_mem(kvm, sfdev->base_addr, sfdev->size,
+			       sfdev->flash_memory);
+
+	if (!ret)
+		sfdev->is_mapped = false;
+
+	return ret;
+}
+
 static void cfi_flash_mmio(struct kvm_cpu *vcpu,
 			   u64 addr, u8 *data, u32 len, u8 is_write,
 			   void *context)
@@ -467,6 +506,12 @@ static void cfi_flash_mmio(struct kvm_cpu *vcpu,
 
 	cfi_flash_write(sfdev, value & 0xffff, faddr, data, len);
 
+	/* Adjust our mapping status accordingly. */
+	if (!sfdev->is_mapped && sfdev->read_mode == READ_ARRAY)
+		map_flash_memory(vcpu->kvm, sfdev);
+	else if (sfdev->is_mapped && sfdev->read_mode != READ_ARRAY)
+		unmap_flash_memory(vcpu->kvm, sfdev);
+
 	mutex_unlock(&sfdev->mutex);
 }
 
@@ -543,6 +588,8 @@ static struct cfi_flash_device *create_flash_device_file(struct kvm *kvm,
 	sfdev->read_mode = READ_ARRAY;
 	sfdev->sr = CFI_STATUS_READY;
 
+	map_flash_memory(kvm, sfdev);
+
 	value = roundup(nr_erase_blocks(sfdev), BITS_PER_LONG) / 8;
 	sfdev->lock_bm = malloc(value);
 	memset(sfdev->lock_bm, 0, value);
-- 
2.17.1

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  parent reply	other threads:[~2020-04-23 17:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23 17:38 [PATCH kvmtool v4 0/5] Add CFI flash emulation Andre Przywara
2020-04-23 17:38 ` [PATCH kvmtool v4 1/5] virtio-mmio: Assign IRQ line directly before registering device Andre Przywara
2020-04-24  8:41   ` Will Deacon
2020-04-24  8:50     ` André Przywara
2020-04-24  9:51       ` Will Deacon
2020-04-23 17:38 ` [PATCH kvmtool v4 2/5] Add emulation for CFI compatible flash memory Andre Przywara
2020-04-23 17:38 ` [PATCH kvmtool v4 3/5] vfio: Destroy memslot when unmapping the associated VAs Andre Przywara
2020-04-23 17:38 ` [PATCH kvmtool v4 4/5] memslot: Add support for READONLY mappings Andre Przywara
2020-04-24  8:41   ` Will Deacon
2020-04-23 17:38 ` Andre Przywara [this message]
2020-04-23 17:55 ` [PATCH kvmtool v4 0/5] Add CFI flash emulation Ard Biesheuvel
2020-04-23 20:43   ` Ard Biesheuvel
2020-04-23 21:31     ` André Przywara
2020-04-24  6:45       ` Ard Biesheuvel
2020-04-24 12:08         ` André Przywara
2020-04-24 12:25           ` Ard Biesheuvel
2020-04-24  8:40 ` Will Deacon
2020-04-24 17:03   ` Will Deacon
2020-04-25 15:16     ` Ard Biesheuvel

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=20200423173844.24220-6-andre.przywara@arm.com \
    --to=andre.przywara@arm.com \
    --cc=ardb@kernel.org \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=raphael.gault@arm.com \
    --cc=sami.mujawar@arm.com \
    --cc=will@kernel.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).