In practice the protocol negotiation between vhost master and slave
occurs before the final feature negotiation between backend and
frontend. This has lead to an inconsistency between the rust-vmm vhost
implementation and the libvhost-user library in their approaches to
checking if all the requirements for REPLY_ACK processing were met.
As this is purely a function of the protocol negotiation and not of
interest to the frontend lets make the language clearer about the
requirements for a successfully negotiated protocol feature.
Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org>
Cc: Jiang Liu <gerry(a)linux.alibaba.com>
---
docs/interop/vhost-user.rst | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index d6085f7045..3ac221a8c7 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -301,12 +301,22 @@ If *slave* detects some error such as incompatible features, it may also
close the connection. This should only happen in exceptional circumstances.
Any protocol extensions are gated by protocol feature bits, which
-allows full backwards compatibility on both master and slave. As
-older slaves don't support negotiating protocol features, a feature
+allows full backwards compatibility on both master and slave. As older
+slaves don't support negotiating protocol features, a device feature
bit was dedicated for this purpose::
#define VHOST_USER_F_PROTOCOL_FEATURES 30
+However as the protocol negotiation something that only occurs between
+parts of the backend implementation it is permissible to for the master
+to mask the feature bit from the guest. As noted for the
+``VHOST_USER_GET_PROTOCOL_FEATURES`` and
+``VHOST_USER_SET_PROTOCOL_FEATURES`` messages this occurs before a
+final ``VHOST_USER_SET_FEATURES`` comes from the guest. So the
+enabling of protocol features need only require the advertising of the
+feature by the slave and the successful get/set protocol features
+sequence.
+
Starting and stopping rings
---------------------------
--
2.20.1
Hi,
These patches have been sitting around as part of a larger series to
improve the support of Xen on AArch64. The second part of the work is
currently awaiting other re-factoring and build work to go in to make
the building of a pure-Xen capable QEMU easier. As that might take
some time and these patches are essentially ready I thought I'd best
push for merging them.
There are no fundamental changes since the last revision. I've
addressed most of the comments although I haven't expanded the use of
the global *fdt to other device models. I figured that work could be
done as and when models have support for type-1 hypervisors.
I have added some documentation to describe the feature and added an
acceptance tests which checks the various versions of Xen can boot.
The only minor wrinkle is using a custom compiled Linux kernel due to
missing support in the distro kernels. If anyone can suggest a distro
which is currently well supported for Xen on AArch64 I can update the
test.
The following patches still need review:
- tests/avocado: add boot_xen tests
- docs: add some documentation for the guest-loader
- docs: move generic-loader documentation into the main manual
- hw/core: implement a guest-loader to support static hypervisor guests
Alex Bennée (7):
hw/board: promote fdt from ARM VirtMachineState to MachineState
hw/riscv: migrate fdt field to generic MachineState
device_tree: add qemu_fdt_setprop_string_array helper
hw/core: implement a guest-loader to support static hypervisor guests
docs: move generic-loader documentation into the main manual
docs: add some documentation for the guest-loader
tests/avocado: add boot_xen tests
docs/generic-loader.txt | 92 ---------
docs/system/generic-loader.rst | 117 +++++++++++
docs/system/guest-loader.rst | 54 +++++
docs/system/index.rst | 2 +
hw/core/guest-loader.h | 34 ++++
include/hw/arm/virt.h | 1 -
include/hw/boards.h | 1 +
include/hw/riscv/virt.h | 1 -
include/sysemu/device_tree.h | 17 ++
hw/arm/virt.c | 356 +++++++++++++++++----------------
hw/core/guest-loader.c | 145 ++++++++++++++
hw/riscv/virt.c | 20 +-
softmmu/device_tree.c | 26 +++
MAINTAINERS | 9 +-
hw/core/meson.build | 2 +
tests/acceptance/boot_xen.py | 117 +++++++++++
16 files changed, 718 insertions(+), 276 deletions(-)
delete mode 100644 docs/generic-loader.txt
create mode 100644 docs/system/generic-loader.rst
create mode 100644 docs/system/guest-loader.rst
create mode 100644 hw/core/guest-loader.h
create mode 100644 hw/core/guest-loader.c
create mode 100644 tests/acceptance/boot_xen.py
--
2.20.1
Hi All
Discussions on low-speed devices were had, there is a proposal to talk
about SCMI server and perhaps RustVMM next call, these have been added to
the agenda.
Some updates on the action item which is copied below, this item will now
be moved to Jira
- Ilias Apalodimas
<https://collaborate.linaro.org/display/~ilias.apalodimas@linaro.org> , Arnd
Bergmann <https://collaborate.linaro.org/display/~arnd@linaro.org> , Alex
Bennée <https://collaborate.linaro.org/display/~alex.bennee@linaro.org> -
chase Kernel on RPMB API, propose spec update to handle eMMC passthrough :
4th Feb 2021 need to talk to Ulf, Arnd says there is a hold up, but need a
proper patch for USFS but the author never followed up, this was up to v7.
there is no proper interface. Arnd / Illias to continue the discussion with
Ulf and perhaps Intel. : Feb 18th API from intel is too detailed, not
useful for RPMB - proposed to list this week. probably have to respin with
a higher-level API for RPMB. If this does not go in OASIS might have to
change. Alex change driver mode of Linux is the best answer
Full notes can be found here
https://collaborate.linaro.org/display/STR/2021-02-18+Project+Stratos+Sync+…
Mike
--
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative; the rest follows."
Hi Gerd,
I was in a discussion with the AGL folks today talking about approaches
to achieving zero-copy when running VirGL virtio guests. AIUI (which is
probably not very much) the reasons for copy can be due to a number of
reasons:
- the GPA not being mapped to a HPA that is accessible to the final HW
- the guest allocation of a buffer not meeting stride/alignment requirements
- data needing to be transformed for consumption by the real hardware?
any others? Is there an impedance between different buffer resource
allocators in the guest and the guest? Is that just a problem for
non-FLOSS blob drivers in the kernel?
I'm curious if it's possible to measure the effect of these extra copies
and where do they occur? Do all resources get copied from the guest buffer to
host or does this only occur when there is a mismatch in the buffer
requirements?
Are there any functions where I could add trace points to measure this?
If this occurs in the kernel I wonder if I could use an eBPF probe to
count the number of bytes copied?
Apologies for the wall of questions I'm still very new to the 3D side of
things ;-)
--
Alex Bennée
Hi All
We don't have an anchor topic for agenda this week, that does not appear to
stop us from making good use of the time, but does anyone have anything
they would like to raise?
https://collaborate.linaro.org/display/STR/Stratos+Home
Mike
--
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative; the rest follows."
Hi All
Thanks for a good call yesterday, meeting notes and Robins RustVMM slides
available at
https://collaborate.linaro.org/display/STR/2021-02-04+Project+Stratos+Sync+…
Mike
--
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative; the rest follows."
Hi All
We have an interesting agenda item for the call this week;
- *Robin Randhawa (Arm) will talk about RustVMM*
Are there any other topics people want to raise?
Meeting: Thursday, 4 February
4:00 – 5:00 pm (GMT+00:00) United Kingdom Time
Virtual meeting: meet.google.com/uak-yrcj-tydhttps://collaborate.linaro.org/display/STR/Stratos+Home
Mike
--
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative; the rest follows."