From: Jan Beulich <jbeulich@suse.com>
To: Teddy Astie <teddy.astie@vates.tech>
Cc: "Juergen Gross" <jgross@suse.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
"Robin Murphy" <robin.murphy@arm.com>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
xen-devel@lists.xenproject.org, iommu@lists.linux.dev
Subject: Re: [RFC PATCH] iommu/xen: Add Xen PV-IOMMU driver
Date: Thu, 13 Jun 2024 16:32:17 +0200 [thread overview]
Message-ID: <8b0151a8-2293-409a-8469-d9e73cf561a3@suse.com> (raw)
In-Reply-To: <fe36b8d36ed3bc01c78901bdf7b87a71cb1adaad.1718286176.git.teddy.astie@vates.tech>
On 13.06.2024 15:50, Teddy Astie wrote:
> @@ -214,6 +215,38 @@ struct xen_add_to_physmap_range {
> };
> DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
>
> +/*
> + * With some legacy devices, certain guest-physical addresses cannot safely
> + * be used for other purposes, e.g. to map guest RAM. This hypercall
> + * enumerates those regions so the toolstack can avoid using them.
> + */
> +#define XENMEM_reserved_device_memory_map 27
> +struct xen_reserved_device_memory {
> + xen_pfn_t start_pfn;
> + xen_ulong_t nr_pages;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_reserved_device_memory);
> +
> +struct xen_reserved_device_memory_map {
> +#define XENMEM_RDM_ALL 1 /* Request all regions (ignore dev union). */
> + /* IN */
> + uint32_t flags;
> + /*
> + * IN/OUT
> + *
> + * Gets set to the required number of entries when too low,
> + * signaled by error code -ERANGE.
> + */
> + unsigned int nr_entries;
> + /* OUT */
> + GUEST_HANDLE(xen_reserved_device_memory) buffer;
> + /* IN */
> + union {
> + struct physdev_pci_device pci;
> + } dev;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_reserved_device_memory_map);
This is a tools-only (i.e. unstable) sub-function in Xen; even the comment
at the top says "toolstack". It is therefore not suitable for use in a
kernel.
> --- /dev/null
> +++ b/include/xen/interface/pv-iommu.h
> @@ -0,0 +1,114 @@
> +/* SPDX-License-Identifier: MIT */
> +/******************************************************************************
> + * pv-iommu.h
> + *
> + * Paravirtualized IOMMU driver interface.
> + *
> + * Copyright (c) 2024 Teddy Astie <teddy.astie@vates.tech>
> + */
> +
> +#ifndef __XEN_PUBLIC_PV_IOMMU_H__
> +#define __XEN_PUBLIC_PV_IOMMU_H__
> +
> +#include "xen.h"
> +#include "physdev.h"
> +
> +#define IOMMU_DEFAULT_CONTEXT (0)
> +
> +/**
> + * Query PV-IOMMU capabilities for this domain.
> + */
> +#define IOMMUOP_query_capabilities 1
> +
> +/**
> + * Allocate an IOMMU context, the new context handle will be written to ctx_no.
> + */
> +#define IOMMUOP_alloc_context 2
> +
> +/**
> + * Destroy a IOMMU context.
> + * All devices attached to this context are reattached to default context.
> + *
> + * The default context can't be destroyed (0).
> + */
> +#define IOMMUOP_free_context 3
> +
> +/**
> + * Reattach the device to IOMMU context.
> + */
> +#define IOMMUOP_reattach_device 4
> +
> +#define IOMMUOP_map_pages 5
> +#define IOMMUOP_unmap_pages 6
> +
> +/**
> + * Get the GFN associated to a specific DFN.
> + */
> +#define IOMMUOP_lookup_page 7
> +
> +struct pv_iommu_op {
> + uint16_t subop_id;
> + uint16_t ctx_no;
> +
> +/**
> + * Create a context that is cloned from default.
> + * The new context will be populated with 1:1 mappings covering the entire guest memory.
> + */
> +#define IOMMU_CREATE_clone (1 << 0)
> +
> +#define IOMMU_OP_readable (1 << 0)
> +#define IOMMU_OP_writeable (1 << 1)
> + uint32_t flags;
> +
> + union {
> + struct {
> + uint64_t gfn;
> + uint64_t dfn;
> + /* Number of pages to map */
> + uint32_t nr_pages;
> + /* Number of pages actually mapped after sub-op */
> + uint32_t mapped;
> + } map_pages;
> +
> + struct {
> + uint64_t dfn;
> + /* Number of pages to unmap */
> + uint32_t nr_pages;
> + /* Number of pages actually unmapped after sub-op */
> + uint32_t unmapped;
> + } unmap_pages;
> +
> + struct {
> + struct physdev_pci_device dev;
> + } reattach_device;
> +
> + struct {
> + uint64_t gfn;
> + uint64_t dfn;
> + } lookup_page;
> +
> + struct {
> + /* Maximum number of IOMMU context this domain can use. */
> + uint16_t max_ctx_no;
> + /* Maximum number of pages that can be modified in a single map/unmap operation. */
> + uint32_t max_nr_pages;
> + /* Maximum device address (iova) that the guest can use for mappings. */
> + uint64_t max_iova_addr;
> + } cap;
> + };
> +};
> +
> +typedef struct pv_iommu_op pv_iommu_op_t;
> +DEFINE_GUEST_HANDLE_STRUCT(pv_iommu_op_t);
> +
> +#endif
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> \ No newline at end of file
Nit: I'm pretty sure you want to avoid this.
Jan
next prev parent reply other threads:[~2024-06-13 14:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 13:50 [RFC PATCH] iommu/xen: Add Xen PV-IOMMU driver Teddy Astie
2024-06-13 14:32 ` Jan Beulich [this message]
2024-06-17 13:36 ` Teddy Astie
2024-06-17 13:36 ` Teddy Astie
2024-06-17 13:43 ` Jan Beulich
2024-06-19 16:30 ` Jason Gunthorpe
2024-06-21 15:09 ` Teddy Astie
2024-06-23 3:21 ` Baolu Lu
2024-06-24 11:09 ` Robin Murphy
2024-06-25 1:18 ` Baolu Lu
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=8b0151a8-2293-409a-8469-d9e73cf561a3@suse.com \
--to=jbeulich@suse.com \
--cc=iommu@lists.linux.dev \
--cc=jgross@suse.com \
--cc=joro@8bytes.org \
--cc=marmarek@invisiblethingslab.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=robin.murphy@arm.com \
--cc=sstabellini@kernel.org \
--cc=teddy.astie@vates.tech \
--cc=will@kernel.org \
--cc=xen-devel@lists.xenproject.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 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.