Hello everyone,
Moving the discussion from google doc [1] to email (Sorry, it was becoming
impossible to follow and reply there).
FWIW, I am not the best person to answer all questions here, that would be
Armelle as she understand the requirements and the end goal much better than I
do. I can though try to answer from kernel's perspective, based on whatever
implementation we have right now.
AFAIK, the broad idea is to implement two virtio communication paths from pVM,
one to the Linux host (via virtio-pci) and another one to Trusty (via
virtio-msg-ffa). In order to not take performance hit at runtime (to map io
buffers), the idea is to map whatever amount of memory we can at the beginning
and then keep allocating from there.
Current setup:
What we have achieved until now is virtio-msg communication between host and
trusty. We have implemented FFA specific dma-hal [2] to perform FFA memory
sharing with trusty. With "reserved-mem" and "memory-region" DT entries (not
sure if that is the final solution), we are able to allocate memory the FFA
device (which represents bus for all the enumerated devices between
trusty/host). This memory is shared with trusty at probe time (from
virtio-msg-ffa layer) and the DMA hal later allocates memory from there for
coherent allocations and bounce buffers. This works just fine right now.
Now looking at "dynamic mapping" section in [1] we are not sure if that will
work fine for the end use case, pVM to trusty. It looks like the coco
implementation will always end up using dma encrypt/decrypt when a pVM is
running and share the memory with host, even when all we want to do is share
with trusty. Is that understanding correct ? We would also want to establish
virtio-pci (existing tech) based communication between pVM and host, which
should use mem decrypt path (?).
I am not sure if we need contiguous PA here, contiguous IPA should be
sufficient, Armelle?
We are also looking for further suggestions to improve the design, as my
understanding of memory mapping, dma hal etc. is limited, and maybe there are
better ways to do this.
--
Viresh
[1] https://docs.google.com/document/d/1KyxclKngQ0MShX8Q1YPstZQVIDIctkxfj6lQ0V3…
[2] https://web.git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/tree/…
Hi Everyone,
I pushed a major change to the pull request for the spec here:
https://github.com/Linaro/virtio-msg-spec/pull/16
I reworked the chapters and the content to look a lot more like other virtio transports and follow the sentence convention (MUST, SHALL, SHOULD).
Some sentences have been reworded with the help of chatgpt so we need to have a careful review of this but i think it looks a lot better than before.
please review based on the final content and not using the tree of patches as the last one is more or less rewriting everything.
Some things to think of:
- message format description: should we switch to structures instead of tables ? I did that for the header and channel I/O is using structures which might look better
- global terminology: i struggle a bit between driver/device vs frontend/backend and we must have a check on the coherency
- compliance: this is the bare output of chatgpt more for discussing than keeping it but it could give us ideas if we want to have something (Warning the compliance chapter content might be wrong).
As always: any comments are welcome :-)
Cheers
Bertrand
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi all,
I was wondering if the virtio-msg demos we have for FFA work on Xen?
I have some vague memory that they do.
I wonder if I can use the same lower-level virtio-msg-bus or ffa calls to move
messages between a DomU/Linux and a QEMU backend in Dom0?
Can someone point me to the code? Or documentation?
Thanks!
Best regards,
Edgar
Hi Everyone,
As you know we have a pending subject around Version handling to solve
to have some kind of "stable" version of the protocol and I think we have
a bit over engineered this so far so i will try to explain my current train of
thoughts so that we could have a productive discussion on Thursday.
What are other transports doing and why ?
- PCI: there is no real protocol version. Capabilities are used and there
is only one used for Legacy devices
- MMIO: One version register which an be 1 or 2, read only from the driver
which is used to inform a driver of the layout of the registers. There is no
negociation
- Channel I/O: A revision, a length and some way to set additional options
depending on the revision. The driver is here telling to the device which
revision of the protocol it wants to use and the device just say no if it
does not support what the driver wants. Once selected any change must be
rejected by the device and the driver must begin by setting it. Somehow
the virtio spec says that this is per device as the only change was a status
message not existing but it is clear that this must be handled at the transport
level and not in a specific driver.
What we need ?
I think we need something very close to what Channel I/O is defining and it
would be a good idea to do reuse the same principles:
- the driver side sets the revision
- the device side just say "Error" if it does not support what is requested
- once the revision is set, only a reset can allow to change it
- driver side should start with highest revision and go down until it finds
a revision it supports
Now I think that having this per device is not useful because we want to
have a generic transport and having different sets of messages per
device due to different revision seems like a complexity
we do not need.
So i think this is something that we should offload at the bus level and
define the following:
- A bus implementation must inform the virtio message generic
transport of the version of the protocol to be used for a specific bus
device instance (ie all devices on this instance will use the same
protocol version). This is to be done through an implementation
defined way.
- A bus implementation must inform the virtio message generic
transport of the maximum message size its support through an
implementation defined way. This can also be per bus device instance.
- It is the bus driver responsibility to negociate a version and maximum
message size with a bus device instance.
- It is the bus device responsibility to know which versions are supported
by its own virtio message generic implementation.
Follwing those principles i would propose to do the following changes in
the specification:
- remove the VIRTIO_MSG_VERSION message
- introduce a BUS_MSG_VERSION message with more or less the same
definition as the current VIRTIO_MSG_VERSION (only simplifying by
saying that the driver sets a version and device say yes or no, the size
would work as it is now)
Some questions for discussion:
- Do you think it is ok to move this to the BUS or should we keep it in
the generic layer to be more "coherent" with other transports ?
- Should we provision something like the "data" part in Channel I/O to
have options on a specific revision ?
- Anything else ?
Cheers
Bertrand
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
