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>
Merge branch 'master' of https://github.com/cloudius-systems/osv
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>
Merge branch 'master' of https://github.com/cloudius-systems/osv