Due to our kernel heritage we have code in kvmtool that relies on
the (still) implicit -std=gnu89 compiler switch.
It turns out that this just affects some structure initialization,
where we currently provide a cast to the type, which upsets GCC for
anything beyond -std=gnu89 (for instance gnu99 or gnu11).
We do need the casts when initializing structures that are not
assigned to the same type, so we put it there explicitly.
This allows us to compile with all the three GNU standards GCC
currently supports: gnu89/90, gnu99 and gnu11.
GCC threatens people with moving to gnu11 as the new default standard,
so lets fix this better sooner than later.
(Compiling without GNU extensions still breaks and I don't bother to
fix that without very good reasons.)
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
dpkg in the guest fails when it tries to use fsync() on a directory:
openat(AT_FDCWD, "/var/lib/dpkg", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
fsync(4) = -1 EINVAL (Invalid argument)
stracing lkvm shows that this is converted to:
openat(AT_FDCWD, "/root/rootfs-32//var/lib/dpkg", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 368
fsync(0) = -1 EINVAL (Invalid argument)
In other words, we sync against the wrong file descriptor. This case
is not handled in the kvmtool code, let's add support for it.
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Will Deacon <will.deacon@arm.com>
The 9p kernel code uses separate types for uid_t and gid_t. To avoid
changing too much code needlessly, copy over the kernel definitions
from uidgid.h into 9p.h.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
If an open at the 9p server(host) fails with EMFILE (Too many open files for
the process), we should return ENFILE(too many open files in the system) to
the guest to indicate the actual status within the guest.
This was uncovered during LTP, where getdtablesize01 fails to open the maximum
number-open-files.
getdtablesize01 0 TINFO : Maximum number of files a process can have opened is 1024
getdtablesize01 0 TINFO : Checking with the value returned by getrlimit...RLIMIT_NOFILE
getdtablesize01 1 TPASS : got correct dtablesize, value is 1024
getdtablesize01 0 TINFO : Checking Max num of files that can be opened by a process.Should be: RLIMIT_NOFILE - 1
getdtablesize01 2 TFAIL : getdtablesize01.c:102: 974 != 1023
For a more practial impact:
# ./getdtablesize01 &
[1] 1834
getdtablesize01 0 TINFO : Maximum number of files a process can have opened is 1024
getdtablesize01 0 TINFO : Checking with the value returned by getrlimit...RLIMIT_NOFILE
getdtablesize01 1 TPASS : got correct dtablesize, value is 1024
getdtablesize01 0 TINFO : Checking Max num of files that can be opened by a process.Should be: RLIMIT_NOFILE - 1
getdtablesize01 2 TFAIL : getdtablesize01.c:102: 974 != 1023
[--- Modified to sleep indefinitely, without closing the files --- ]
# ls
bash: /bin/ls: Too many open files
That gives a wrong error message for the bash, when getdtablesize01 has exhausted the system
wide limits, giving false indicators.
With the fix, we get :
# ls
bash: /bin/ls: Too many open files in system
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Configure the queues to follow the guest endianness, and make sure
the configuration space is doing the same.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Upstream commit "9p: Modify the stat structures to use kuid_t and kgid_t"
has modified the type of uid and gid in the stat structure, which breaks
build for us.
This is a rather trivial conversion from u32 to kuid_t and kgid_t.
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch changes VIRTIO_DEFAULT_TRANS to take a struct kvm parameter,
allowing architectures to choose the default transport dynamically.
For ARM, this is driven by an arch-specific cmdline option.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Commit "kvm tools: virtio: remove hardcoded assumptions
about guest page size" has introduced a bug that prevented
guests with more than 4gb of ram from booting.
The issue is that 'pfn' is a 32bit integer, so when multiplying
it by page size to get the actual page will cause an overflow if
the pfn referred to a memory area above 4gb.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Commit 447c50943fd0 ("9p: Modify the stat structures to use kuid_t and
kgid_t") broke the 9p backend by introducing the k{u,g}id_t types, which
aren't currently in scope.
Just fix the damn thing by including linux/uidgid.h.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
virtio-based PCI devices deal only with 4k memory granules, making
direct use of the VIRTIO_PCI_VRING_ALIGN and VIRTIO_PCI_QUEUE_ADDR_SHIFT
constants when initialising the virtqueues for a device.
For MMIO-based devices, the guest page size is arbitrary and may differ
from that of the host (this is the case on AArch64, where both 4k and
64k pages are supported).
This patch fixes the virtio drivers to honour the guest page size passed
when configuring the virtio device and align the virtqueues accordingly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Some architectures may provide only a restricted PCI implementation and
therefore prefer MMIO as the transport for virtio devices.
This patch allows the arch backend to specify the default virtio
transport. Some devices (e.g. net) allow the transport to be overriden
by the user and are left alone by this change.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
When a guest kernel initialises a virtio device using an MMIO transport,
it attempts to set the size of the virtual queue. For devices that expect
a PCI transport, this is not the case and, as such, our console, 9p and
rng virtio devices do not set a pointer for this function and subsequently
SEGV.
This patch adds a dummy implementation of the function to avoid the fatal
signal.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Creating new files in a guest:
echo "hello, world" > hello.txt
results in EPERM on my machine.
The problem is that virtio_p9_create() calls lchown() on UID zero (we
are logged in as root in the guest) which obviously doesn't work. In
fact, ownership changes can't work unless we have some sort of uid/gid
mapping. Therefore, drop the calls to lchown().
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Switch to using init/exit calls instead of the repeating call blocks in builtin-run.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Sort out init/exit calls, move parser into the 9p code and make sure
rootfs config is initialized before virtio-9p (or any other init func)
is called.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
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>
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>
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>
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>
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>
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>
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>
Since virtio-mmio was introduced in 3.2, virtio-pci isn't the only transport
layer between the kernel and virtio devices.
This patch adds an abstract virtio-transport layer which allows to easily
use different transports while making it transparent to the device.
This is the first step in adding virtio-mmio support.
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
All the virtio pci device is set to class code 0x010000, this is wrong.
This patch sets the correct class code and makes lspci report correct
class type. For example, the net device:
Before:
$ lspci
00:03.0 SCSI storage controller: Red Hat, Inc Virtio network device
After:
$ lspci
00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
Acked-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 removed ioeventfd registration from devices and moves it
to a single place in virtio-pci layer.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch implement dotl protocol for the server. 9p2000.L enables better
interop with Linux client and offers larger set of features.
Acked-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The virtio_p9_set_reply_header function looks at the pdu buffer to find the cmd
so that it can find the reply command value. We actually found the issue when
Sasha reported that dd on his system in failing with unknown error 512 with
dotl. The reason being that, since we didn't update iovec in virtio_p9_write
virtio_p9_set_reply_header was looking at a wrong offset and the reply cmd got
set to RLERROR, and the client picked the bytes written as errno number.
We need to restore the value properly so that rest of readf and writef
work as expected.
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch adds support for the UNIX extensions to 9p2000.
Supporting thses extensions allow us to transperantly mount UNIX directories
without missing features such as symlinks.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
James Hunt