From: David Hildenbrand <david@redhat.com>
To: Matthew Rosato <mjrosato@linux.ibm.com>, qemu-s390x@nongnu.org
Cc: farman@linux.ibm.com, schnelle@linux.ibm.com, thuth@redhat.com,
pasic@linux.ibm.com, borntraeger@linux.ibm.com,
richard.henderson@linaro.org, iii@linux.ibm.com,
clegoate@redhat.com, qemu-devel@nongnu.org
Subject: Re: [PATCH 1/2] s390x/pci: add support for guests that request direct mapping
Date: Mon, 9 Dec 2024 22:01:44 +0100 [thread overview]
Message-ID: <f7451934-bf20-4c50-8780-4d5ebf932096@redhat.com> (raw)
In-Reply-To: <20241209192927.107503-2-mjrosato@linux.ibm.com>
On 09.12.24 20:29, Matthew Rosato wrote:
> When receiving a guest mpcifc(4) or mpcifc(6) instruction without the T
> bit set, treat this as a request to perform direct mapping instead of
> address translation. In order to facilitiate this, pin the entirety of
> guest memory into the host iommu.
>
> Subsequent guest DMA operations are all expected to be of the format
> guest_phys+sdma, allowing them to be used as lookup into the host
> iommu table.
>
> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
> ---
> hw/s390x/s390-pci-bus.c | 23 ++++++++++++++++++
> hw/s390x/s390-pci-inst.c | 42 +++++++++++++++++++++++++++++++--
> include/hw/s390x/s390-pci-bus.h | 2 ++
> 3 files changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index 40b2567aa7..8d4224e032 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -18,6 +18,7 @@
> #include "hw/s390x/s390-pci-inst.h"
> #include "hw/s390x/s390-pci-kvm.h"
> #include "hw/s390x/s390-pci-vfio.h"
> +#include "hw/boards.h"
> #include "hw/pci/pci_bus.h"
> #include "hw/qdev-properties.h"
> #include "hw/pci/pci_bridge.h"
> @@ -720,6 +721,27 @@ void s390_pci_iommu_enable(S390PCIIOMMU *iommu)
> TYPE_S390_IOMMU_MEMORY_REGION, OBJECT(&iommu->mr),
> name, iommu->pal + 1);
> iommu->enabled = true;
> + iommu->direct_map = false;
> + memory_region_add_subregion(&iommu->mr, 0, MEMORY_REGION(&iommu->iommu_mr));
> + g_free(name);
> +}
> +
> +void s390_pci_iommu_dm_enable(S390PCIIOMMU *iommu)
> +{
> + MachineState *ms = MACHINE(qdev_get_machine());
> +
> + /*
> + * For direct-mapping we must map the entire guest address space. Because
> + * the mappings are contiguous we are not restricted to individual 4K
> + * mappings via vfio, so let's not worry about the DMA limit when
> + * calculating the range.
> + */
> + char *name = g_strdup_printf("iommu-s390-%04x", iommu->pbdev->uid);
> + memory_region_init_iommu(&iommu->iommu_mr, sizeof(iommu->iommu_mr),
> + TYPE_S390_IOMMU_MEMORY_REGION, OBJECT(&iommu->mr),
> + name, iommu->pba + ms->ram_size);
> + iommu->enabled = true;
> + iommu->direct_map = true;
> memory_region_add_subregion(&iommu->mr, 0, MEMORY_REGION(&iommu->iommu_mr));
> g_free(name);
> }
> @@ -727,6 +749,7 @@ void s390_pci_iommu_enable(S390PCIIOMMU *iommu)
> void s390_pci_iommu_disable(S390PCIIOMMU *iommu)
> {
> iommu->enabled = false;
> + iommu->direct_map = false;
> g_hash_table_remove_all(iommu->iotlb);
> memory_region_del_subregion(&iommu->mr, MEMORY_REGION(&iommu->iommu_mr));
> object_unparent(OBJECT(&iommu->iommu_mr));
> diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
> index 41655082da..f4d8fe8fe8 100644
> --- a/hw/s390x/s390-pci-inst.c
> +++ b/hw/s390x/s390-pci-inst.c
> @@ -16,6 +16,7 @@
> #include "exec/memory.h"
> #include "qemu/error-report.h"
> #include "sysemu/hw_accel.h"
> +#include "hw/boards.h"
> #include "hw/pci/pci_device.h"
> #include "hw/s390x/s390-pci-inst.h"
> #include "hw/s390x/s390-pci-bus.h"
> @@ -990,6 +991,33 @@ int pci_dereg_irqs(S390PCIBusDevice *pbdev)
> return 0;
> }
>
> +static void s390_pci_setup_stage2_map(S390PCIIOMMU *iommu)
> +{
> + MachineState *ms = MACHINE(qdev_get_machine());
> + uint64_t remain = ms->ram_size, start = iommu->pba, mask, size, curr = 0;
> + uint64_t end = start + remain - 1;
> + IOMMUTLBEvent event = {
> + .type = IOMMU_NOTIFIER_MAP,
> + .entry = {
> + .target_as = &address_space_memory,
> + .translated_addr = 0,
> + .perm = IOMMU_RW,
> + },
> + };
> +
> + while (remain >= TARGET_PAGE_SIZE) {
> + mask = dma_aligned_pow2_mask(start, end, 64);
> + size = mask + 1;
> + event.entry.iova = start;
> + event.entry.addr_mask = mask;
> + event.entry.translated_addr = curr;
> + memory_region_notify_iommu(&iommu->iommu_mr, 0, event);
> + start += size;
> + curr += size;
> + remain -= size;
> + }
> +}
Hi,
Trying to wrap my head around that ... you mention that "pin the
entirety of guest memory".
Do you mean that we will actually end up longterm pinning all guest RAM
in the kernel, similar to what vfio ends up doing?
In that case, it would be incompatible with virtio-balloon (and without
modifications with upcoming virtio-mem). Is there already a mechanism in
place to handle that -- a call to ram_block_discard_disable() -- or
even a way to support coordinated discarding of RAM (e.g., virtio-mem +
vfio)?
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-12-09 21:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 19:29 [PATCH 0/2] s390x/pci: relax I/O address translation requirement Matthew Rosato
2024-12-09 19:29 ` [PATCH 1/2] s390x/pci: add support for guests that request direct mapping Matthew Rosato
2024-12-09 21:01 ` David Hildenbrand [this message]
2024-12-09 21:45 ` Matthew Rosato
2024-12-09 22:09 ` David Hildenbrand
2024-12-09 23:22 ` Matthew Rosato
2024-12-10 8:58 ` David Hildenbrand
2024-12-13 22:46 ` Matthew Rosato
2024-12-11 11:34 ` Thomas Huth
2024-12-11 14:40 ` Cédric Le Goater
2024-12-11 15:17 ` Matthew Rosato
2024-12-09 19:29 ` [PATCH 2/2] s390x/pci: indicate QEMU supports relaxed translation for passthrough Matthew Rosato
2024-12-11 11:40 ` Thomas Huth
2024-12-12 9:10 ` [PATCH 0/2] s390x/pci: relax I/O address translation requirement Thomas Huth
2024-12-12 14:42 ` Matthew Rosato
2024-12-13 9:07 ` Cédric Le Goater
2024-12-13 9:24 ` 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=f7451934-bf20-4c50-8780-4d5ebf932096@redhat.com \
--to=david@redhat.com \
--cc=borntraeger@linux.ibm.com \
--cc=clegoate@redhat.com \
--cc=farman@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=mjrosato@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=schnelle@linux.ibm.com \
--cc=thuth@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.