elf: support R_X86_64_COPY relocation

this relocation was necessary to run netperf.so

Signed-off-by: Claudio Fontana <claudio.fontana@huawei.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
scripts: add script to setup a development environment

Installs all required packages.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
acpi: shutdown OSv on power button ACPI event

Signed-off-by: Gleb Natapov <gleb@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
acpi: run interrupt handler in a thread

ACPI interrupt handlers are allowed to take locks, so we must run them in
a thread.  Add a class to take care of this, arranging for the thread to
exit when done.

Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
sendmsg: kern_sendit(): create a local copy of user's iovec

kern_sendit() calls for sosend() which changes the contents of iovec
in its uio parameter (specifically as a result of uiomove() call).

Before this patch we just set uio->uio_iov to be mp->msg_iov which comes
from the application and applications assume msg_iov is not changed
(e.g. memcached).

As a result the application may get seriously confused. For example, memcached
will send corrupted responces when value size is greater than MTU, e.g. 5024B,
for 1500B MTU.

The easiest way to fix this is to create a local copy of iovec. We may consider
some more creative approach in a future.

Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
run: "fix" redis boot.

I have finally found what was preventing redis from booting reliably. Two main
comments about it:

1) I have *absolutely no idea* why it was working so well before. The fpu thing
was really a red herring, nothing to do with it.

2) I believe this is technically a redis bug. However, I kind of agree with
Linus in the now famous memcpy discussion he had: just because something is (or
fail to be) in a written specification, doesn't mean we should go assigning
blame around. In the end, what matters is what works vs what doesn't

The problem is simple: redis assumes the the strings in the argv array are
contiguous in memory. They do that in such a conscious and well though manner,
that led me to believe that maybe this is specified somewhere. I didn't find
anything saying that this is a requirement. Still, redis does it.

Because they assume contiguous storage, they memset the whole region between
start and end with 0. Our strings start contiguous, because we get them from
the command line, but in the last stage of composing the array we copy them
over. If redis is ran with a single parameter, this is not a problem. But we
specify a configuration file. Also, if the memory allocator happens to make the
strings contiguous, there won't be a problem. If they are close enough, there
will be a problem but maybe we won't notice it (the likely scenario so far)

As I have said, I really have no idea why at some point in time (around the fpu
commits) that becomes more likely. Maybe this is due to Pawel's allocator
changes: they are also nearby the fpu commits and could have tricked me.

All in all, but in redis or not, I will advocate for us fixing this in OSv.
Maybe there are other people making such assumptions out there? The proposed
fix is easy: in the last step before calling main, copy all strings to a
contiguous buffer.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
virtio::net::txq: Use proper size of virtio_net_hdr

According to virtio specification virtio_net_hdr should include
num_buffers field only if VIRTIO_NET_F_MRG_RXBUF feature is negotiated.
Although this field is not used in the Tx flow its presence impacts
the size of the whole virtio_net_hdr struct. Therefore it should be taken
into an account when posting a virtio_net_hdr in a Tx flow.

The above has been broken by commit f99c90b9 and this patch fixes it back.

Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Reported-by:   Gleb Natapov <gleb@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Add missing cfgetispeed()

Add the missing trivial function from termios(3).

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Fix cfset*speed() nonsense

The termios(3) line speed thing is not interesting, but nevertheless,
if we implement cf{set,get}[io]speed() functions, let's at least do it
right.

The current code was a weird, and wrong, combination of archaic Unix and
Linux. In archaic Unix, there was one speed setting for both input and
output, and it was controlled in the c_cflag field of the termios structure,
with the bitmask CBAUD. But Posix allows two separate speeds - input and
output - and doesn't specify where they are kept. Linux/Glibc keeps them in
seperate fields of the termios structure (c_ispeed, c_ospeed), so to be
ABI-compatible with Linux we also have these fields in the structure, and
should use them.

To summarize, our getispeed()/getospeed() functions were correct, reading
the relevant fields of the termios structure, but setispeed()/setospeed(),
apparently copied from musl, were using the old CBAUD technique and didn't
fit what we did in getispeed()/getospeed()! So this patch modifies the set()
functions to match the get() functions. They also now match the glibc
implementation.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Fix cfsetspeed()

According to termios(3), cfsetspeed() should set both input and output
speed.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Fix bug in readv() and fread()

readv() takes a pointer to *const* iovecs, meaning it isn't allowed to change
them. Unfortunately, our internal read implementation did modify the iovecs,
zeroing their length field. It turns out that this non-conformity with the
standard also breaks our fread() implementation, which uses readv() and
assumes it doesn't touch the iovec's lengths, so without this patch fread()
with large enough lengths will return garbage.

Interestingly, the compiler should have warned us about writing to a const
field, except we had an explicit cast (!) removing the constness. Yuck.

The solution is to copy the iovecs in sys_read (the new vector is allocated
on the heap). Interestingly, the existing code already used a silly function
"copyinuio" which allocated the "uio" structure on the heap, which we didn't
need to do, and forgot to copy the iovec, which it needed to. So use correct
inline code instead of the useless copyinuio().

Fixes #354.

In separate patches I will provide a test case for this bug, and also the same
patch for writev() and perhaps other users of copyinuio().

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
zfs: align vdev_label_t buffer to page boundary

Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
xen: align grant table to page boundary

Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
vmxnet3: Fix TSO support on VMware Player/Workstation/Fusion

There's a report that TSO support on VMware Player/Workstation/Fusion was broken on upstream OS of this driver(FreeBSD):
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185849
This patch is backported from the fix on FreeBSD:
http://svnweb.freebsd.org/base?view=revision&revision=267253

fixed #340

Signed-off-by: Takuya ASADA <syuu@cloudius-systems.com>
Reviewed-by: Dmitry Fleytman <dmitry@daynix.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Remove dead code

Remove copyinuio() function. Not needed any more, and shouldn't be needed
in the future (there is no reason to allocate a uio on the heap, and there's
a reason to copy the iovecs, which this function didn't).

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Remove double include

Signed-off-by: KANATSU Minoru <icc.pot.tyew272@gmail.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
tcp: trim mbuf to IP packet length in the net channel path

Fixes #342.

According to RFC894 the minimum ethernet frame size is 60 bytes. When
the packet is smaller than that it should be padded. Looks like vmxnet
in constrast to virtio-net respects this rule and pads small packets
with zeros.

FreeBSD's stack is prepared for this, the mbuf is trimmed in
ip_preprocess_packet() which is called from ip_input(). However our
net channel fast path did not have this logic. This patch adds the
missing processing to tcp_net_channel_packet().

Reported-by: Lyor Goldstein <lgoldstein@vmware.com>
Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Test readv() and fread()

This test confirms bug issue #354, and verifies its fix.

It demonstrates that readv() wrongly modified its const parameter, and
fread() returned garbage data (compared to the correct data returned by
getc() and read()), and that after this bug's fix, both readv() and
fread() work correctly.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
Fix writev() as well

This patch fixes a bug in writev() identical to the one we already fixed
in readv() - it illegally modified its const argument.

The patch also adds to tests/tst-uio.cc a test for this bug.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
elf: warn when using unsupported combination of PIE and TLS

As explained in issue #352, a PIE (position-independent executable) using
TLS (thread-local storage) does not currently work correctly. Fixing this
case is not easy, but until we do, it is dangerous to allow this case to
be ignored, as it causes reading and writing to wrong positions in memory
whenever TLS is used in the PIE.

So this patch adds a warning printout (to stdout) whenever one attempts to
load a PIE which has any TLS variables.

This is, of course, just a temporary measure. The real solution is to fix
object load and not just warn.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>