Hello,
This patchset adds toolstack support for I2C and GPIO virtio devices. This is
inspired from the work done by Oleksandr for the Disk device [1].
The first two patches can be applied right away, but the last two need
Oleksandr's series [1] to be applied first.
This is developed as part of Linaro's Project Stratos, where we are working
towards Hypervisor agnostic Rust based backend [2].
I must accept that I am a beginner to Xen and developed this patchset based on
support for existing devices like Disk or Keyboard. There may be bits which I
missed or the one I added which aren't really required.
Thanks.
--
Viresh
Viresh Kumar (4):
libxl: Add support for Virtio I2C device
libxl: Add support for Virtio GPIO device
libxl: Allocate MMIO params for I2c device and update DT
libxl: Allocate MMIO params for GPIO device and update DT
tools/golang/xenlight/helpers.gen.go | 220 ++++++++++++++++++++
tools/golang/xenlight/types.gen.go | 54 +++++
tools/include/libxl.h | 64 ++++++
tools/include/libxl_utils.h | 6 +
tools/libs/light/Makefile | 2 +
tools/libs/light/libxl_arm.c | 117 ++++++++++-
tools/libs/light/libxl_create.c | 26 +++
tools/libs/light/libxl_dm.c | 34 +++-
tools/libs/light/libxl_gpio.c | 236 ++++++++++++++++++++++
tools/libs/light/libxl_i2c.c | 236 ++++++++++++++++++++++
tools/libs/light/libxl_internal.h | 2 +
tools/libs/light/libxl_types.idl | 52 +++++
tools/libs/light/libxl_types_internal.idl | 2 +
tools/ocaml/libs/xl/genwrap.py | 2 +
tools/ocaml/libs/xl/xenlight_stubs.c | 2 +
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 6 +
tools/xl/xl_cmdtable.c | 30 +++
tools/xl/xl_gpio.c | 143 +++++++++++++
tools/xl/xl_i2c.c | 143 +++++++++++++
tools/xl/xl_parse.c | 160 +++++++++++++++
tools/xl/xl_parse.h | 2 +
tools/xl/xl_sxp.c | 4 +
23 files changed, 1540 insertions(+), 5 deletions(-)
create mode 100644 tools/libs/light/libxl_gpio.c
create mode 100644 tools/libs/light/libxl_i2c.c
create mode 100644 tools/xl/xl_gpio.c
create mode 100644 tools/xl/xl_i2c.c
--
2.31.1.272.g89b43f80a514
[1] https://lore.kernel.org/xen-devel/1649442065-8332-1-git-send-email-olekstys…
[2] https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i…
When we introduced FEAT_LPA to QEMU's -cpu max we discovered older
kernels had a bug where the physical address was copied directly from
ID_AA64MMFR0_EL1.PARange field. The early cpu_init code of Xen commits
the same error by blindly copying across the max supported range.
Unsurprisingly when the page tables aren't set up for these greater
ranges hilarity ensues and the hypervisor crashes fairly early on in
the boot-up sequence. This happens when we write to the control
register in enable_mmu().
Attempt to fix this the same way as the Linux kernel does by gating
PARange to the maximum the hypervisor can handle. I also had to fix up
code in p2m which panics when it sees an "invalid" entry in PARange.
Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org>
Cc: Richard Henderson <richard.henderson(a)linaro.org>
Cc: Stefano Stabellini <sstabellini(a)kernel.org>
Cc: Julien Grall <julien(a)xen.org>
Cc: Volodymyr Babchuk <Volodymyr_Babchuk(a)epam.com>
Cc: Bertrand Marquis <bertrand.marquis(a)arm.com>
---
xen/arch/arm/arm64/head.S | 6 ++++++
xen/arch/arm/p2m.c | 9 ++++++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index aa1f88c764..057dd5d925 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -473,6 +473,12 @@ cpu_init:
ldr x0, =(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(64-48))
/* ID_AA64MMFR0_EL1[3:0] (PARange) corresponds to TCR_EL2[18:16] (PS) */
mrs x1, ID_AA64MMFR0_EL1
+ /* Limit to 48 bits, 256TB PA range (#5) */
+ ubfm x1, x1, #0, #3
+ mov x2, #5
+ cmp x1, x2
+ csel x1, x1, x2, lt
+
bfi x0, x1, #16, #3
msr tcr_el2, x0
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index fb71fa4c1c..e5a88095f8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -2030,7 +2030,7 @@ void __init setup_virt_paging(void)
unsigned int root_order; /* Page order of the root of the p2m */
unsigned int sl0; /* Desired SL0, maximum in comment */
} pa_range_info[] = {
- /* T0SZ minimum and SL0 maximum from ARM DDI 0487A.b Table D4-5 */
+ /* T0SZ minimum and SL0 maximum from ARM DDI 0487H.a Table D5-6 */
/* PA size, t0sz(min), root-order, sl0(max) */
[0] = { 32, 32/*32*/, 0, 1 },
[1] = { 36, 28/*28*/, 0, 1 },
@@ -2038,7 +2038,7 @@ void __init setup_virt_paging(void)
[3] = { 42, 22/*22*/, 3, 1 },
[4] = { 44, 20/*20*/, 0, 2 },
[5] = { 48, 16/*16*/, 0, 2 },
- [6] = { 0 }, /* Invalid */
+ [6] = { 52, 12/*12*/, 3, 3 },
[7] = { 0 } /* Invalid */
};
@@ -2069,10 +2069,13 @@ void __init setup_virt_paging(void)
}
}
- /* pa_range is 4 bits, but the defined encodings are only 3 bits */
+ /* pa_range is 4 bits but we don't support all modes */
if ( pa_range >= ARRAY_SIZE(pa_range_info) || !pa_range_info[pa_range].pabits )
panic("Unknown encoding of ID_AA64MMFR0_EL1.PARange %x\n", pa_range);
+ if ( pa_range > 5 )
+ pa_range = 5;
+
val |= VTCR_PS(pa_range);
val |= VTCR_TG0_4K;
--
2.30.2
Hi,
The following is a breakdown (as best I can figure) of the work needed
to demonstrate VirtIO backends in Rust on the Xen hypervisor. It
requires work across a number of projects but notably core rust and virtio
enabling in the Xen project (building on the work EPAM has already done)
and the start of enabling rust-vmm crate to work with Xen.
The first demo is a fairly simple toy to exercise the direct hypercall
approach for a unikernel backend. On it's own it isn't super impressive
but hopefully serves as a proof of concept for the idea of having
backends running in a single exception level where latency will be
important.
The second is a much more ambitious bridge between Xen and vhost-user to
allow for re-use of the existing vhost-user backends with the bridge
acting as a proxy for what would usually be a full VMM in the type-2
hypervisor case. With that in mind the rust-vmm work is only aimed at
doing the device emulation and doesn't address the larger question of
how type-1 hypervisors can be integrated into the rust-vmm hypervisor
model.
A quick note about the estimates. They are exceedingly rough guesses
plucked out of the air and I would be grateful for feedback from the
appropriate domain experts on if I'm being overly optimistic or
pessimistic.
The links to the Stratos JIRA should be at least read accessible to all
although they contain the same information as the attached document
(albeit with nicer PNG renderings of my ASCII art ;-). There is a
Stratos sync-up call next Thursday:
https://calendar.google.com/event?action=TEMPLATE&tmeid=MWpidm5lbzM5NjlydnA…
and I'm sure there will also be discussion in the various projects
(hence the wide CC list). The Stratos calls are open to anyone who wants
to attend and we welcome feedback from all who are interested.
So on with the work breakdown:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STRATOS PLANNING FOR 21 TO 22
Alex Bennée
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Table of Contents
─────────────────
1. Xen Rust Bindings ([STR-51])
.. 1. Upstream an "official" rust crate for Xen ([STR-52])
.. 2. Basic Hypervisor Interactions hypercalls ([STR-53])
.. 3. [#10] Access to XenStore service ([STR-54])
.. 4. VirtIO support hypercalls ([STR-55])
2. Xen Hypervisor Support for Stratos ([STR-56])
.. 1. Stable ABI for foreignmemory mapping to non-dom0 ([STR-57])
.. 2. Tweaks to tooling to launch VirtIO guests
3. rust-vmm support for Xen VirtIO ([STR-59])
.. 1. Make vm-memory Xen aware ([STR-60])
.. 2. Xen IO notification and IRQ injections ([STR-61])
4. Stratos Demos
.. 1. Rust based stubdomain monitor ([STR-62])
.. 2. Xen aware vhost-user master ([STR-63])
1 Xen Rust Bindings ([STR-51])
══════════════════════════════
There exists a [placeholder repository] with the start of a set of
x86_64 bindings for Xen and a very basic hello world uni-kernel
example. This forms the basis of the initial Xen Rust work and will be
available as a [xen-sys crate] via cargo.
[STR-51] <https://linaro.atlassian.net/browse/STR-51>
[placeholder repository] <https://gitlab.com/cardoe/oxerun.git>
[xen-sys crate] <https://crates.io/crates/xen-sys>
1.1 Upstream an "official" rust crate for Xen ([STR-52])
────────────────────────────────────────────────────────
To start with we will want an upstream location for future work to be
based upon. The intention is the crate is independent of the version
of Xen it runs on (above the baseline version chosen). This will
entail:
• ☐ agreeing with upstream the name/location for the source
• ☐ documenting the rules for the "stable" hypercall ABI
• ☐ establish an internal interface to elide between ioctl mediated
and direct hypercalls
• ☐ ensure the crate is multi-arch and has feature parity for arm64
As such we expect the implementation to be standalone, i.e. not
wrapping the existing Xen libraries for mediation. There should be a
close (1-to-1) mapping between the interfaces in the crate and the
eventual hypercall made to the hypervisor.
Estimate: 4w (elapsed likely longer due to discussion)
[STR-52] <https://linaro.atlassian.net/browse/STR-52>
1.2 Basic Hypervisor Interactions hypercalls ([STR-53])
───────────────────────────────────────────────────────
These are the bare minimum hypercalls implemented as both ioctl and
direct calls. These allow for a very basic binary to:
• ☐ console_io - output IO via the Xen console
• ☐ domctl stub - basic stub for domain control (different API?)
• ☐ sysctl stub - basic stub for system control (different API?)
The idea would be this provides enough hypercall interface to query
the list of domains and output their status via the xen console. There
is an open question about if the domctl and sysctl hypercalls are way
to go.
Estimate: 6w
[STR-53] <https://linaro.atlassian.net/browse/STR-53>
1.3 [#10] Access to XenStore service ([STR-54])
───────────────────────────────────────────────
This is a shared configuration storage space accessed via either Unix
sockets (on dom0) or via the Xenbus. This is used to access
configuration information for the domain.
Is this needed for a backend though? Can everything just be passed
direct on the command line?
Estimate: 4w
[STR-54] <https://linaro.atlassian.net/browse/STR-54>
1.4 VirtIO support hypercalls ([STR-55])
────────────────────────────────────────
These are the hypercalls that need to be implemented to support a
VirtIO backend. This includes the ability to map another guests memory
into the current domains address space, register to receive IOREQ
events when the guest knocks at the doorbell and inject kicks into the
guest. The hypercalls we need to support would be:
• ☐ dmop - device model ops (*_ioreq_server, setirq, nr_vpus)
• ☐ foreignmemory - map and unmap guest memory
The DMOP space is larger than what we need for an IOREQ backend so
I've based it just on what arch/arm/dm.c exports which is the subset
introduced for EPAM's virtio work.
Estimate: 12w
[STR-55] <https://linaro.atlassian.net/browse/STR-55>
2 Xen Hypervisor Support for Stratos ([STR-56])
═══════════════════════════════════════════════
These tasks include tasks needed to support the various different
deployments of Stratos components in Xen.
[STR-56] <https://linaro.atlassian.net/browse/STR-56>
2.1 Stable ABI for foreignmemory mapping to non-dom0 ([STR-57])
───────────────────────────────────────────────────────────────
Currently the foreign memory mapping support only works for dom0 due
to reference counting issues. If we are to support backends running in
their own domains this will need to get fixed.
Estimate: 8w
[STR-57] <https://linaro.atlassian.net/browse/STR-57>
2.2 Tweaks to tooling to launch VirtIO guests
─────────────────────────────────────────────
There might not be too much to do here. The EPAM work already did
something similar for their PoC for virtio-block. Essentially we need
to ensure:
• ☐ DT bindings are passed to the guest for virtio-mmio device
discovery
• ☐ Our rust backend can be instantiated before the domU is launched
This currently assumes the tools and the backend are running in dom0.
Estimate: 4w
3 rust-vmm support for Xen VirtIO ([STR-59])
════════════════════════════════════════════
This encompasses the tasks required to get a vhost-user server up and
running while interfacing to the Xen hypervisor. This will require the
xen-sys.rs crate for the actual interface to the hypervisor.
We need to work out how a Xen configuration option would be passed to
the various bits of rust-vmm when something is being built.
[STR-59] <https://linaro.atlassian.net/browse/STR-59>
3.1 Make vm-memory Xen aware ([STR-60])
───────────────────────────────────────
The vm-memory crate is the root crate for abstracting access to the
guests memory. It currently has multiple configuration builds to
handle difference between mmap on Windows and Unix. Although mmap
isn't directly exposed the public interfaces support a mmap like
interface. We would need to:
• ☐ work out how to expose foreign memory via the vm-memory mechanism
I'm not sure if this just means implementing the GuestMemory trait for
a GuestMemoryXen or if we need to present a mmap like interface.
Estimate: 8w
[STR-60] <https://linaro.atlassian.net/browse/STR-60>
3.2 Xen IO notification and IRQ injections ([STR-61])
─────────────────────────────────────────────────────
The KVM world provides for ioeventfd (notifications) and irqfd
(injection) to signal asynchronously between the guest and the
backend. As far a I can tell this is currently handled inside the
various VMMs which assume a KVM backend.
While the vhost-user slave code doesn't see the
register_ioevent/register_irqfd events it does deal with EventFDs
throughout the code. Perhaps the best approach here would be to create
a IOREQ crate that can create EventFD descriptors which can then be
passed to the slaves to use for notification and injection.
Otherwise there might be an argument for a new crate that can
encapsulate this behaviour for both KVM/ioeventd and Xen/IOREQ setups?
Estimate: 8w?
[STR-61] <https://linaro.atlassian.net/browse/STR-61>
4 Stratos Demos
═══════════════
These tasks cover the creation of demos that brig together all the
previous bits of work to demonstrate a new area of capability that has
been opened up by Stratos work.
4.1 Rust based stubdomain monitor ([STR-62])
────────────────────────────────────────────
This is a basic demo that is a proof of concept for a unikernel style
backend written in pure Rust. This work would be a useful precursor
for things such as the RTOS Dom0 on a safety island ([STR-11]) or as a
carrier for the virtio-scmi backend.
The monitor program will periodically poll the state of the other
domains and echo their status to the Xen console.
Estimate: 4w
#+name: stub-domain-example
#+begin_src ditaa :cmdline -o :file stub_domain_example.png
Dom0 | DomU | DomStub
| |
: /-------------\ :
| |cPNK | |
| | | |
| | | |
/------------------------------------\ | | GuestOS | |
|cPNK | | | | |
EL0 | Dom0 Userspace (xl tools, QEMU) | | | | | /---------------\
| | | | | | |cYEL |
\------------------------------------/ | | | | | |
+------------------------------------+ | | | | | Rust Monitor |
EL1 |cA1B Dom0 Kernel | | | | | | |
+------------------------------------+ | \-------------/ | \---------------/
-------------------------------------------------------------------------------=------------------
+-------------------------------------------------------------------------------------+
EL2 |cC02 Xen Hypervisor |
+-------------------------------------------------------------------------------------+
#+end_src
[STR-62] <https://linaro.atlassian.net/browse/STR-62>
[STR-11] <https://linaro.atlassian.net/browse/STR-11>
4.2 Xen aware vhost-user master ([STR-63])
──────────────────────────────────────────
Usually the master side of a vhost-user system is embedded directly in
the VMM itself. However in a Xen deployment their is no overarching
VMM but a series of utility programs that query the hypervisor
directly. The Xen tooling is also responsible for setting up any
support processes that are responsible for emulating HW for the guest.
The task aims to bridge the gap between Xen's normal HW emulation path
(ioreq) and VirtIO's userspace device emulation (vhost-user). The
process would be started with some information on where the
virtio-mmio address space is and what the slave binary will be. It
will then:
• map the guest into Dom0 userspace and attach to a MemFD
• register the appropriate memory regions as IOREQ regions with Xen
• create EventFD channels for the virtio kick notifications (one each
way)
• spawn the vhost-user slave process and mediate the notifications and
kicks between the slave and Xen itself
#+name: xen-vhost-user-master
#+begin_src ditaa :cmdline -o :file xen_vhost_user_master.png
Dom0 DomU
|
|
|
|
|
|
+-------------------+ +-------------------+ |
| |----------->| | |
| vhost-user | vhost-user | vhost-user | : /------------------------------------\
| slave | protocol | master | | | |
| (existing) |<-----------| (rust) | | | |
+-------------------+ +-------------------+ | | |
^ ^ | ^ | | Guest Userspace |
| | | | | | |
| | | IOREQ | | | |
| | | | | | |
v v V | | \------------------------------------/
+---------------------------------------------------+ | +------------------------------------+
| ^ ^ | ioctl ^ | | | |
| | iofd/irqfd eventFD | | | | | | Guest Kernel |
| +---------------------------+ | | | | | +-------------+ |
| | | | | | | virtio-dev | |
| Host Kernel V | | | | +-------------+ |
+---------------------------------------------------+ | +------------------------------------+
| ^ | | ^
| hyper | | |
----------------------=------------- | -=--- | ----=------ | -----=- | --------=------------------
| call | Trap | | IRQ
V | V |
+-------------------------------------------------------------------------------------+
| | ^ | ^ |
| | +-------------+ | |
EL2 | Xen Hypervisor | | |
| +-------------------------------+ |
| |
+-------------------------------------------------------------------------------------+
#+end_src
[STR-63] <https://linaro.atlassian.net/browse/STR-63>
--
Alex Bennée
Hello,
This patchset adds vhost-user-gpio device's support in Qemu. The support for the
same has already been added to virtio specification and Linux Kernel.
A Rust based backend is also in progress and is tested against this patchset:
https://github.com/rust-vmm/vhost-device/pull/76
--
Viresh
Viresh Kumar (2):
hw/virtio: add boilerplate for vhost-user-gpio device
hw/virtio: add vhost-user-gpio-pci boilerplate
hw/virtio/Kconfig | 5 +
hw/virtio/meson.build | 2 +
hw/virtio/vhost-user-gpio-pci.c | 69 ++++++
hw/virtio/vhost-user-gpio.c | 343 ++++++++++++++++++++++++++++
include/hw/virtio/vhost-user-gpio.h | 35 +++
5 files changed, 454 insertions(+)
create mode 100644 hw/virtio/vhost-user-gpio-pci.c
create mode 100644 hw/virtio/vhost-user-gpio.c
create mode 100644 include/hw/virtio/vhost-user-gpio.h
--
2.31.1.272.g89b43f80a514
Hi,
Currently there are 3 responses to the doodle poll so can I encourage
people to vote:
https://doodle.com/meeting/participate/id/vbm0MG9a
so I can lock in the time and date on Monday evening. I'll set it to
repeat at least until DST changes again.
As for topics I'm hoping we'll have some news to discuss on the xen
vhost-user work or at least some deep technical issues to talk about.
Anything else people want to discuss?
--
Alex Bennée
Hi,
While we've been working on the rust-vmm virtio backends on Xen we
obviously have to map guest memory info the userspace of the daemon.
However following the logic of what is going on is a little confusing.
For example in the Linux backend we have this:
void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, void *addr,
int prot, int flags, size_t num,
const xen_pfn_t arr[/*num*/], int err[/*num*/])
{
int fd = fmem->fd;
privcmd_mmapbatch_v2_t ioctlx;
size_t i;
int rc;
addr = mmap(addr, num << XC_PAGE_SHIFT, prot, flags | MAP_SHARED,
fd, 0);
if ( addr == MAP_FAILED )
return NULL;
ioctlx.num = num;
ioctlx.dom = dom;
ioctlx.addr = (unsigned long)addr;
ioctlx.arr = arr;
ioctlx.err = err;
rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
Where the fd passed down is associated with the /dev/xen/privcmd device
for issuing hypercalls on userspaces behalf. What is confusing is why
the function does it's own mmap - one would assume the passed addr would
be associated with a anonymous or file backed mmap region already that
the calling code has setup. Applying a mmap to a special device seems a
little odd.
Looking at the implementation on the kernel side it seems the mmap
handler only sets a few flags:
static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
{
/* DONTCOPY is essential for Xen because copy_page_range doesn't know
* how to recreate these mappings */
vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTCOPY |
VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_ops = &privcmd_vm_ops;
vma->vm_private_data = NULL;
return 0;
}
So can I confirm that the mmap of /dev/xen/privcmd is being called for
side effects? Is it so when the actual ioctl is called the correct flags
are set of the pages associated with the user space virtual address
range?
Can I confirm there shouldn't be any limitation on where and how the
userspace virtual address space is setup for the mapping in the guest
memory?
Is there a reason why this isn't done in the ioctl path itself?
I'm trying to understand the differences between Xen and KVM in the API
choices here. I think the equivalent is the KVM_SET_USER_MEMORY_REGION
ioctl for KVM which brings a section of the guest physical address space
into the userspaces vaddr range.
--
Alex Bennée
Hi,
I gather everyone had a good discussion about Xen/SCMI APIs last
meeting. Is there more to be discussed?
Otherwise does anyone have any other topics they want to discuss?
I've noticed a drop off in external contributors and I know some people
have clashes on their diaries. Should we consider maybe moving the call
to another time?
I'm also conscious that Stratos is the last project standing that has
yet to switch to the sprint process. Should we discuss the best cycle
time for that as well?
--
Alex Bennée
Hi Stefano,
Vincent gave an update on his virtio-scmi work at the last Stratos sync
call and the discussion moved onto next steps. Currently the demo setup
is intermediated by a double-ended vhost-user daemon running on the
devbox acting as a go between a number of QEMU instances representing
the front and back-ends. You can view the architecture with Vincents
diagram here:
https://docs.google.com/drawings/d/1YSuJUSjEdTi2oEUq4oG4A9pBKSEJTAp6hhcHKKh…
The key virtq handling is done over the special carve outs of shared
memory between the front end and guest. However the signalling is
currently over a virtio device on the backend. This is useful for the
PoC but obviously in a real system we don't have a hidden POSIX system
acting as a go between not to mention the additional latency it causes
with all those context switches.
I was hoping we could get some more of the Xen experts to the next
Stratos sync (17th Feb) to go over approaches for a properly hosted on
Xen approach. From my recollection (Vincent please correct me if I'm
wrong) of last week the issues that need solving are:
* How to handle configuration steps as FE guests come up
The SCMI server will be a long running persistent backend because it is
managing real HW resources. However the guests may be ephemeral (or just
restarted) so we can't just hard-code everything in a DTB. While the
virtio-negotiation in the config space covers most things we still need
information like where in the guests address space the shared memory
lives and at what offset into that the queues are created. As far as I'm
aware the canonical source of domain information is XenStore
(https://wiki.xenproject.org/wiki/XenStore) but this relies on a Dom0
type approach. Is there an alternative for dom0less systems or do we
need a dom0-light approach, for example using STR-21 (Ensure Zephyr can
run cleanly as a Dom0 guest) providing just enough services for FE's to
register metadata and BE's to read it?
* How to handle mapping of memory
AIUI the Xen model is the FE guest explicitly makes grant table requests
to expose portions of it's memory to other domains. Can the BE query the
hypervisor itself to discover the available grants or does it require
coordination with Dom0/XenStore for that information to be available to
the BE domain?
* How to handle signalling
I guess this requires a minimal implementation of the IOREQ calls for
Zephyr so we can register the handler in the backend? Does the IOREQ API
allow for a IPI style notifications using the global GIC IRQs?
Forgive the incomplete notes from the Stratos sync, I was trying to type
while participating in the discussion so hopefully this email captures
what was missed:
https://linaro.atlassian.net/wiki/spaces/STR/pages/28682518685/2022-02-03+P…
Vincent, anything to add?
--
Alex Bennée
Hi Ruchika,
I just wanted to check what was required for you to make progress using
virtio-rpmb. We've updated the spec for multi-block and I think
implementing it in the C version of the backend is pretty trivial. The
main thing I need is a decent way to test it.
The original backend was tested with the out of tree virtio-rpmb driver
which I hacked up to meet the spec. However my proposal for a new kernel
ABI fell flat:
Subject: [RFC PATCH 0/5] RPMB internal and user-space API + WIP virtio-rpmb frontend
Date: Wed, 3 Mar 2021 13:54:55 +0000
Message-Id: <20210303135500.24673-1-alex.bennee(a)linaro.org>
the main issue being not wanting to delegate crypto to inside the
kernel. So we need to return to doing the frame calculations externally
to the kernel and it simply acting as a conduit for the virtio frames. I
can just hack up my original test branch for multi-block although it
seems such a driver is unlikely to be merged anyway so it would just be
an out-of-tree testing branch.
Ilias mentioned we could test if he completes his uboot driver but I
recall there where some questions about how it fitted into u-boots
driver structure (i.e. being treated as a real device). For your work do
you still need a Linux driver for the rpmb anyway?
--
Alex Bennée
