> set in cpu_exec_loop
It should be possible to rule out the jump cache in HEAD by patching out
the two:
if (likely(tb &&
tb->pc == pc &&
tb->cs_base == cs_base &&
d the canonical source of truth for any
implementation (Linux or otherwise).
By all means have the distilled documentation for the driver in the
kernel source tree but trying to upstream an implementation before
starting the definition in the standard is a little back to front IMHO*.
* that's not
Joakim Bech writes:
> On Fri, Sep 25, 2020 at 01:51:43PM +0100, Alex Bennée wrote:
>> With this command we are finally updating data to the backing store
>> and cycling the write_count and each successful write. We also include
>> the write count in all response frames as
what the key is so it can do other operations.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 37
1 file changed, 37 insertions(+)
diff --git a/tools/vhost-user-rpmb/main.c b/tools/vhost-user-rpmb/main.c
index 49d4e00b24a9..34607ad19429 100644
Basic usage and example invocation.
Signed-off-by: Alex Bennée
---
docs/tools/index.rst | 1 +
docs/tools/vhost-user-rpmb.rst | 102 +
2 files changed, 103 insertions(+)
create mode 100644 docs/tools/vhost-user-rpmb.rst
diff --git a/docs/tools
With this command we are finally updating data to the backing store
and cycling the write_count and each successful write. We also include
the write count in all response frames as the spec is a little unclear
but the example test code expected it.
Signed-off-by: Alex Bennée
---
tools/vhost
This is the first function with an implied response that doesn't need
a VIRTIO_RPMB_REQ_RESULT_READ.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 44
1 file changed, 44 insertions(+)
diff --git a/tools/vhost-user-rpmb/main.c b/tools/
if we should respond immediately or on request]
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 299 +--
1 file changed, 286 insertions(+), 13 deletions(-)
diff --git a/tools/vhost-user-rpmb/main.c b/tools/vhost-user-rpmb/main.c
index 64bd7e79f573
This is mostly useful for testing. Practically all guest operations
will probe the write count before any write transaction.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/vhost-user-rpmb/main.c b/tools/vhost-user-rpmb
The read command is a lot simpler to implement. However the spec does
specify you can only read a single block at a time so we limit it to
that.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 52
1 file changed, 52 insertions(+)
diff --git a
SIGINT/SIGHUP termination
signal. While we are at it add some instrumentation so we can follow
the program flow.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 49 +++-
1 file changed, 43 insertions(+), 6 deletions(-)
diff --git a/tools/vhost-user
Again doesn't do much on it's own but will create a socket and wait on
messages coming in from the vhost-user message socket.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 211 +-
tools/vhost-user-rpmb/meson.build | 2 +-
2 files ch
We need to calculate HMAC-256SHA as part of the protocol. To avoid
making the daemon dependent on QEMU's internal crypto library we
import the functions here.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/hmac_sha256.h | 87
tools/vhost-user-rpmb/hmac_sha256.c
We will need to store the data somewhere so add the option to point to
the file where we will keep the data.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 58 +++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/tools/vhost-user-rpmb
A very simple capabilities dump.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/vhost-user-rpmb/main.c b/tools/vhost-user-rpmb/main.c
index a40a680a74ca..6b1989125bd6 100644
--- a/tools/vhost-user-rpmb/main.c
Signed-off-by: Alex Bennée
---
hw/virtio/virtio-pci.c | 3 +++
hw/virtio/trace-events | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 507cb57c410f..33a40e31d955 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio
This allows is to instantiate a vhost-user-rpmb device as part of a
PCI bus. It is mostly boilerplate which looks pretty similar to the
vhost-user-fs-pci device if you squint.
Signed-off-by: Alex Bennée
---
- enable use IOEVENTFD flag
- swap obj set bool args
---
hw/block/vhost-user-rpmb
This creates the QEMU side of the vhost-user-rpmb device which
connects to the remote daemon. It is based of the reasonably modern
vhost-user-fs code with bits from vhost-user-blk as we want the
virtio-config itself to be sourced from the daemon.
Signed-off-by: Alex Bennée
---
include/hw/virtio
This gives us two levels of informational output when tracing what the
daemon is doing.
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tools/vhost-user-rpmb/main.c b/tools/vhost-user-rpmb/main.c
index
If you like running QEMU as a normal user (very common for TCG runs)
but you have to run virtiofsd as a root user you run into connection
problems. Adding support for an optional --socket-group allows the
users to keep using the command line.
Signed-off-by: Alex Bennée
Reviewed-by: Stefan
This allows other device classes that will be exposed via PCI to be
able to do so in the appropriate hw/ directory. I resisted the
temptation to re-order headers to be more aesthetically pleasing.
Signed-off-by: Alex Bennée
---
{hw => include/hw}/virtio/virtio-pci.h | 0
hw/virtio/vhost-s
useful
output you get is when running:
vhost-user-rpmb --help
Signed-off-by: Alex Bennée
---
tools/vhost-user-rpmb/main.c | 37 ++
MAINTAINERS| 5 +++
tools/meson.build | 8 +
tools/vhost-user-rpmb/50
gratefully received as well as discussion about if
we should consider creating some new projects for housing these sort
of vhost-user backends.
Alex Bennée (19):
tools/virtiofsd: add support for --socket-group
hw/block: add boilerplate for vhost-user-rpmb device
hw/virtio: move virtio-pci.h
it was worth removing the file-system integration
patches and just posting a series which implements the rpmb char device,
userspace tool and the virtio-rpmb driver?
>
>
> Am 10.09.20 um 15:08 schrieb Alex Bennée:
>> CAUTION: This email originated from outside of the organization.
Alex Bennée writes:
> Hi,
>
> The specification lists a number of commands that have responses:
>
> The operation of a virtio RPMB device is driven by the requests placed
> on the virtqueue. The type of request can be program key
> (VIRTIO_RPMB_REQ_PROGRAM_KE
free(frame_res);
return ret;
}
although I'm guessing this might just be an impedance between the
chardev ioctl interface for rpmb and the virtio FE driver which is only
one potential consumer of these rpmb ioc commands?
Can anyone clarify?
--
Alex Bennée
_
Jan Kiszka writes:
> On 28.02.20 11:30, Jan Kiszka wrote:
>> On 28.02.20 11:16, Alex Bennée wrote:
>>> Hi,
>>>
>>> I believe there has been some development work for supporting VIRTIO on
>>> Xen although it seems to have stalled according to
Paolo Bonzini writes:
> On 28/02/20 11:16, Alex Bennée wrote:
>> - How about HyperV and the OSX equivalent?
>
> OS X Hypervisor.framework just uses QEMU, so it can use virtio devices
> too. VirtualBox also supports virtio devices.
I guess these don't do any sort
this would allow Xen (and other hypervisors) a simple
way to be able to carry virtio traffic between guest and end point.
So some questions:
- Am I missing anything out in that summary?
- How about HyperV and the OSX equivalent?
- Do any other type-1 hypervisors support virt
elp
> + This module implements a virtio transport for Virtual Sockets.
> +
> + Enable this transport if your Virtual Machine runs on
> Qemu/KVM.
Is this better worded as:
"Enable this transport if your Virtual Machine host supports vsockets
over virtio.
et_init,
> + .destruct = virtio_transport_destruct,
> + .release = virtio_transport_release,
> + .connect = virtio_transport_connect,
> + .shutdown = virtio_transport_shutdown,
> +
&
virtio_transport_recv_pkt_work);
> + INIT_WORK(&vsock->tx_work, virtio_transport_send_pkt_work);
> +
> + mutex_lock(&vsock->rx_lock);
> + virtio_vsock_rx_fill(vsock);
> + mutex_unlock(&vsock->rx_lock);
> +
> + mutex_unlock(&the_virti
virtio_transport_send_reset(vsk, pkt);
> + return -ENOMEM;
> + }
> +
> + pr_debug("%s: create pending\n", __func__);
> + child = __vsock_create(sock_net(sk), NULL, sk, GFP_KERNEL,
> +sk->sk_type, 0);
> + if (!chil
33 matches
Mail list logo
