Instead of a get/set for config values, just request the address of the
config region, and handle that by simply reading directly from that region.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
We're not supposed to kill all fids when a new attach request
arrives. This used to cause issues when the guest would send
multiple attach requests.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Fix up warnings related to not checking return value of read/write by actually
handling errors there.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
We still create GSIs and keep them for two reasons:
- They're required by virtio-* devices.
- There's not much overhead since we just create them when starting the
guest, they don't use anything when the guest is running.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch brings virito-scsi support to kvm tool.
With the introduce of tcm_vhost (vhost-scsi)
tcm_vhost: Initial merge for vhost level target fabric driver
we can implement virito-scsi by simply having vhost-scsi to handle the
SCSI command.
Howto use:
1) Setup the tcm_vhost target through /sys/kernel/config
[Stefan Hajnoczi, Thanks for the script to setup tcm_vhost]
** Setup wwpn and tpgt
$ wwpn="naa.0"
$ tpgt=/sys/kernel/config/target/vhost/$wwpn/tpgt_0
$ nexus=$tpgt/nexus
$ mkdir -p $tpgt
$ echo -n $wwpn > $nexus
** Setup lun using /dev/ram
$ n=0
$ lun=$tpgt/lun/lun_${n}
$ data=/sys/kernel/config/target/core/iblock_0/data_${n}
$ ram=/dev/ram${n}
$ mkdir -p $lun
$ mkdir -p $data
$ echo -n udev_path=${ram} > $data/control
$ echo -n 1 > $data/enable
$ ln -s $data $lun
2) Run kvm tool with the new disk option '-d scsi:$wwpn:$tpgt', e.g
$ lkvm run -k /boot/bzImage -d ~/img/sid.img -d scsi:naa.0:0
Signed-off-by: Asias He <asias.hejun@gmail.com>
Cc: Nicholas A. Bellinger <nab@linux-iscsi.org>
Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This error message is missing a space, and has a redundant ":" at the end,
currently it produces:
You have requested a TAP device, but creation of one hasfailed because:: No such file or directory
Add a space to "hasfailed" and remove the extra ":".
Don't split the line to improve grepability.
Acked-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This is something we can calculate on the fly, and doesn't justify the overhead
of tracking it all over fid transitions.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This removes the limit for p9 fids and the huge fid array that came along with
it. Instead, it dynamically allocates fids and stores them in a rb-tree.
This is useful when the guest needs a lot of fids, such as when stress
testing guests.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
If vhost is enabled for a virtio device, vhost will poll the ioeventfd
in kernel side and there is no need to poll it in userspace. Otherwise,
both vhost kernel and userspace will race to poll.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
VHOST_SET_MEM_TABLE failed: Operation not supported
In vhost_set_memory(), We have
if (mem.padding)
return -EOPNOTSUPP;
So, we need to zero struct vhost_memory.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
While we process 9p requests serially, so there's no point for implementing
flush, we still need to answer it to prevent guest kernel from hanging waiting
for it.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
All blk requests are processed in notify_vq() which is in the context of
ioeventfd thread: ioeventfd__thread(). The processing in notify_vq() may
take a long time to complete and all devices share the single ioeventfd
thead, so this might block other device's notify_vq() being called and
starve other devices.
This patch makes virtio blk's notify_vq() just notify the blk thread
instead of doing the real hard read/write work. Tests show that the
overhead of the notification operations is small.
The reasons for using dedicated thead instead of using thead pool
follow:
1) In thread pool model, each job handling operation:
thread_pool__do_job() takes about 6 or 7 mutex_{lock,unlock} ops. Most
of the mutex are global (job_mutex) which are contented by the threads
in the pool. It's fine for the non performance critical virtio devices,
such as console, rng, etc. But it's not optimal for net and blk devices.
2) Using dedicated threads to handle blk requests opens the door for
user to set different IO priority for the blk threads.
3) It also reduces the contentions between net and blk devices if they
do not share the thead pool.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
---------
Before:
---------
*** Compatibility Warning ***
virtio-blk device was not detected
While you have requested a virtio-blk device, the guest kernel did not initialize it.
Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_BLK=y enabled in its .config
*** Compatibility Warning ***
virtio-net device was not detected
While you have requested a virtio-net device, the guest kernel did not initialize it.
Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_NET=y enabled in its .config
# KVM session ended normally.
---------
After:
---------
# KVM compatibility warning.
virtio-blk device was not detected.
While you have requested a virtio-blk device, the guest kernel did not initialize it.
Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_BLK=y enabled in .config.
# KVM compatibility warning.
virtio-net device was not detected.
While you have requested a virtio-net device, the guest kernel did not initialize it.
Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_NET=y enabled in .config.
# KVM session ended normally.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
compat_id is initialized to -1 for each type of device. We should add
compat message if the compat_id == -1 which means we haven't added
compat message for this type of device.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch introduces a helper virtio_compat_add_message() to simplify
adding compat message for virtio device.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The req_mutex was used to protect the request list. In commit b7b038d, I
removed the use of the virtio_blk_req_{pop, push} which needs the
req_mutex, but I forgot to remove the req_mutex. So remove it now.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Since the 9p functions don't know the size of the fid array, they might
request an FID outside of the allowed range. Use an accessor to prevent
that and to hide the internal implementation from them.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
set_size_vq does not do the actual work, we can implement this later.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
set_size_vq does not do the actual work, we can implement this later.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Increase virtio-blk and virtio-net queue size to 256.
This makes virtio-mmio work.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
To select virtio-mmio instead of virito-pci transport:
lkvm run --network trans=mmio
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch is based on Sasha's 'kvm tools: Add support for virtio-mmio'
patch. ioeventfds support is added which was missing in the previous one.
VQ size/align is still not supported.
It adds support for the new virtio-mmio transport layer added in
3.2-rc1. The purpose of this new layer is to allow virtio to work on
systems which don't necessarily support PCI, such as embedded systems.
To apply the patch on top of the KVM tools tree, you must first pull
Linus' tree on top. Also, CONFIG_VIRTIO_MMIO=y should be set in the
guest kernel.
To easily test it it's recommended to apply Pawel Moll's patch named
'virtio-mmio: Devices parameter parsing' on top, and define the
virtio-mmio device using kernel command line.
LKVM will print a message to help user to figure out how to add kernel
command line to support virtio-mmio.
To instantiate guest virtio-mmio devices using kernel command line (or
module) parameter, e.g.
virtio_mmio.devices=0x200@0xd2000000:5,0x200@0xd2000200:6
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch reworks on virtio transport abstraction.
* Move virtio transport operations to virtio operations and drop
virtio/trans.c This makes the abstraction much cleaner.
* Rename struct virtio_trans to struct virtio_device
struct virtio_trans {
void *virtio;
enum virtio_trans_type type;
struct virtio_trans_ops *trans_ops;
struct virtio_ops *virtio_ops;
};
struct virtio_device {
void *virtio;
struct virtio_ops *ops;
};
The virtio_trans struct is bit confusing since it also includes virtio
operations.
* Introduce virtio_init()
To init device, e.g.
Before:
virtio_trans_init()
ndev->vtrans.trans_ops->init()
ndev->vtrans.virtio_ops = &net_dev_virtio_ops
After:
virtio_init()
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Add is_pio flag to set KVM_IOEVENTFD_FLAG_PIO. This is useful for
attaching an ioeventfd to MMIO address as well as PIO address.
virtio-mmio needs an ioeventfd to MMIO address.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch fixes the following valgrind reported memory leak:
==7684== 20 bytes in 8 blocks are definitely lost in loss record 3 of 46
==7684== at 0x4A0649D: malloc (vg_replace_malloc.c:236)
==7684== by 0x4116B5: virtio_p9_pdu_readf (9p-pdu.c:110)
==7684== by 0x40FD8C: virtio_p9_attach (9p.c:354)
==7684== by 0x410E80: virtio_p9_do_io (9p.c:1154)
==7684== by 0x40DB45: thread_pool__threadfunc (threadpool.c:56)
==7684== by 0x3DE7007B30: start_thread (in /lib64/libpthread-2.14.so)
==7684== by 0x3DE68DFD2C: clone (in /lib64/libc-2.14.so)
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch fixes the following valgrind reported memory leak in
virtio_9p_walk():
==6689== 1,058 bytes in 134 blocks are definitely lost in loss record 39 of 47
==6689== at 0x4A0649D: malloc (vg_replace_malloc.c:236)
==6689== by 0x4116A9: virtio_p9_pdu_readf (9p-pdu.c:110)
==6689== by 0x40FB9F: virtio_p9_walk (9p.c:305)
==6689== by 0x410E73: virtio_p9_do_io (9p.c:1151)
==6689== by 0x40DB45: thread_pool__threadfunc (threadpool.c:56)
==6689== by 0x3DE7007B30: start_thread (in /lib64/libpthread-2.14.so)
==6689== by 0x3DE68DFD2C: clone (in /lib64/libc-2.14.so)
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The commit 2b6c246215e8f936d2366ef8c4a6eec730b819b2
(kvm tools: Use compat message per device instead of per instance)
prevents multiple messages for the same type of device.
The variable compat_id is expected to be initialized to -1.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Remove struct balloon_cmd and use kvm_ipc__send_msg().
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Coalescing MMIOs is only required when we really want avoid having to exit
to userspace for every MMIO write, usually it's not the case so no reason
to coalesce every MMIO zone (I was also pretty sure it didn't always coalesce
zones)..
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Free up the BAR to make space for the new virtio BARs. It isn't required
to have the PBA and the table in the separate BARs, and uniting them will
just give us extra BARs to play with.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
We don't really support that, so no point in using 64bit BARs.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The BAR addresses are set up fine, but missed the bar_size[] array which is now
updated correspondingly.
Use PCI_IO_SIZE instead of '0x100'.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
vesa, pci-shmem and virtio-pci devices need to set up config space with
little-endian conversions (as config space is LE). The pci_config_address
bitfield also needs to be reversed when building on BE systems.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Sasha Levin