On 10/20/2016 07:30 AM, Fam Zheng wrote:
On Thu, 10/20 15:08, Stefan Hajnoczi wrote:
If a corrupt image is able to execute arbitrary code in the qemu-tcmu
process, does /dev/uio0 or the tcmu shared memory interface allow get
root or kernel privileges?
I haven't audited the code, but target_cor
On 09/04/2014 06:24 AM, Benoît Canet wrote:
There are other commands for snapshots and backup which are issued via
QMP.
It might even make sense to make the tcmu interface available at
run-time in QEMU like the run-time NBD server. This allows you to get
at read-only point-in-time snapshots whi
On 09/02/2014 02:25 AM, Stefan Hajnoczi wrote:
The easiest approach is to write a tool similar to qemu-nbd that speaks
the userspace target protocol (i.e. mmap the shared memory).
If the tcmu setup code is involved, maybe providing a libtcmu with the
setup code would be useful. I suspect that
On 08/30/2014 09:02 AM, Richard W.M. Jones wrote:
On Sat, Aug 30, 2014 at 05:53:43PM +0200, Benoît Canet wrote:
If the cloud provider want to be able to boot QCOW2 or QED images on
bare metal machines he will need to export QCOW2 or QED images on
the network.
So far only qemu-nbd allows to do t
On 08/29/2014 11:51 AM, Benoît Canet wrote:
QMP is just a way to control QEMU via a socket: it is not particularly block
related.
On the other hand bringing the whole block layers into a tcmu-runner handler
would mean that there would be _one_ QMP socket opened
(by mean of wonderfull QEMU modul
On 08/29/2014 10:22 AM, Benoît Canet wrote:
The truth is that QEMU block drivers don't know how to do much on their own
so we probably must bring the whole QEMU block layer in a tcmu-runner handler
plugin.
Woah! Really? ok...
Another reason to do this is that the QEMU block layer brings fea
