[Qemu-devel] [RFC] linux-user (mostly syscall.c)

[Qemu-devel] [RFC] linux-user (mostly syscall.c)

[Thayne Harbaugh]

There are several things that I'd like to see addressed in linux-user.
Some of these are to fix bugs, some are to make qemu linux-user more
like the Linux kernel, some are to make the internal qemu interfaces
more consistent.

An internal coding practice that is being addressed bit-by-bit is that
of managing the interface between the host and the target.  Currently
this is a bit sloppy and inconsistent (some of which I've contributed
to).  There are examples of using target addresses for host pointers and
host errnos for target errnos, using different types between target and
host that don't sign-extend properly, as well as other things.  This
causes compiler warnings to actual run-time bugs.  Currently I'm
reviewing all of the linux-user code (mostly syscall.c) to fix these
inconsistencies.  I will be writing developer documentation describing
the coding practices that should govern the target/host interface and
submitting patches for the fixes.

As obvious as it may seem I'll re-state that the linux-user emulation is
emulating the Linux kernel (duh!).  There are portions of qemu
linux-user that are even excerpted directly from the Linux kernel.
Consequently it is useful for internal qemu data and functions to
closely mimic the kernel for best code sharing.  There are also
advantages to even structuring qemu directly and file organization in
similar divisions, groupings and locations.  Some of this organization
might lead to good division so that other user/kernel divisions are
cleaner (different kernel versions, other OSes - darwin-user and
others).

Internal qemu interfaces are consistent - except when they aren't.  This
causes coding errors when passing target and host arguments or return
codes.  I'll be documenting the coding practices as well as submitting
patches to make these consistent.  (That sounds a bit redundant with
other things I've mentioned).

I have about 40 patches already worked up that do this.  Some of those
patches might be broken up smaller.  The qemu that we've been working
with is nearly rock solid (still a few more bugs being wrung out).  It
can nearly build an entire Debian arm distribution for an arm target
being hosted on x86_64.  We're quite excited to get our patches upstream
so that others can benefit and to ease our maintenance overhead.  We're
also turning our focus to PPC and other archs.

Please let me know if you support the general idea of the coding changes
above: General clean-up, consistent target/host interfaces, file
splitting/reorganizing, etc..  In the meantime I'll be putting together
the developer documentation/coding guidelines for review.

Thank you.

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[Thiemo Seufer]

Thayne Harbaugh wrote:
> There are several things that I'd like to see addressed in linux-user.
> Some of these are to fix bugs, some are to make qemu linux-user more
> like the Linux kernel, some are to make the internal qemu interfaces
> more consistent.
> 
> An internal coding practice that is being addressed bit-by-bit is that
> of managing the interface between the host and the target.  Currently
> this is a bit sloppy and inconsistent (some of which I've contributed
> to).  There are examples of using target addresses for host pointers and
> host errnos for target errnos, using different types between target and
> host that don't sign-extend properly, as well as other things.  This
> causes compiler warnings to actual run-time bugs.  Currently I'm
> reviewing all of the linux-user code (mostly syscall.c) to fix these
> inconsistencies.  I will be writing developer documentation describing
> the coding practices that should govern the target/host interface and
> submitting patches for the fixes.
> 
> As obvious as it may seem I'll re-state that the linux-user emulation is
> emulating the Linux kernel (duh!).  There are portions of qemu
> linux-user that are even excerpted directly from the Linux kernel.
> Consequently it is useful for internal qemu data and functions to
> closely mimic the kernel for best code sharing.  There are also
> advantages to even structuring qemu directly and file organization in
> similar divisions, groupings and locations.  Some of this organization
> might lead to good division so that other user/kernel divisions are
> cleaner (different kernel versions, other OSes - darwin-user and
> others).
> 
> Internal qemu interfaces are consistent - except when they aren't.  This
> causes coding errors when passing target and host arguments or return
> codes.  I'll be documenting the coding practices as well as submitting
> patches to make these consistent.  (That sounds a bit redundant with
> other things I've mentioned).
> 
> I have about 40 patches already worked up that do this.  Some of those
> patches might be broken up smaller.  The qemu that we've been working
> with is nearly rock solid (still a few more bugs being wrung out).  It
> can nearly build an entire Debian arm distribution for an arm target
> being hosted on x86_64.  We're quite excited to get our patches upstream
> so that others can benefit and to ease our maintenance overhead.  We're
> also turning our focus to PPC and other archs.
> 
> Please let me know if you support the general idea of the coding changes
> above: General clean-up, consistent target/host interfaces, file
> splitting/reorganizing, etc..  In the meantime I'll be putting together
> the developer documentation/coding guidelines for review.

FWIW, I agree with everything you said above.


Thiemo

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[J. Mayer]

On Sat, 2007-11-03 at 01:21 +0000, Thiemo Seufer wrote:
> Thayne Harbaugh wrote:
> > There are several things that I'd like to see addressed in linux-user.
> > Some of these are to fix bugs, some are to make qemu linux-user more
> > like the Linux kernel, some are to make the internal qemu interfaces
> > more consistent.
> > 
> > An internal coding practice that is being addressed bit-by-bit is that
> > of managing the interface between the host and the target.  Currently
> > this is a bit sloppy and inconsistent (some of which I've contributed
> > to).  There are examples of using target addresses for host pointers and
> > host errnos for target errnos, using different types between target and
> > host that don't sign-extend properly, as well as other things.  This
> > causes compiler warnings to actual run-time bugs.  Currently I'm
> > reviewing all of the linux-user code (mostly syscall.c) to fix these
> > inconsistencies.  I will be writing developer documentation describing
> > the coding practices that should govern the target/host interface and
> > submitting patches for the fixes.
> > 
> > As obvious as it may seem I'll re-state that the linux-user emulation is
> > emulating the Linux kernel (duh!).  There are portions of qemu
> > linux-user that are even excerpted directly from the Linux kernel.
> > Consequently it is useful for internal qemu data and functions to
> > closely mimic the kernel for best code sharing.  There are also
> > advantages to even structuring qemu directly and file organization in
> > similar divisions, groupings and locations.  Some of this organization
> > might lead to good division so that other user/kernel divisions are
> > cleaner (different kernel versions, other OSes - darwin-user and
> > others).
> > 
> > Internal qemu interfaces are consistent - except when they aren't.  This
> > causes coding errors when passing target and host arguments or return
> > codes.  I'll be documenting the coding practices as well as submitting
> > patches to make these consistent.  (That sounds a bit redundant with
> > other things I've mentioned).
> > 
> > I have about 40 patches already worked up that do this.  Some of those
> > patches might be broken up smaller.  The qemu that we've been working
> > with is nearly rock solid (still a few more bugs being wrung out).  It
> > can nearly build an entire Debian arm distribution for an arm target
> > being hosted on x86_64.  We're quite excited to get our patches upstream
> > so that others can benefit and to ease our maintenance overhead.  We're
> > also turning our focus to PPC and other archs.
> > 
> > Please let me know if you support the general idea of the coding changes
> > above: General clean-up, consistent target/host interfaces, file
> > splitting/reorganizing, etc..  In the meantime I'll be putting together
> > the developer documentation/coding guidelines for review.
> 
> FWIW, I agree with everything you said above.

I agree too.
Code cleanup and sanitization is needed there.
I'm just reserved about the code splitting point: as for the vl.h
splitting, it should not lead to get files with only a single or two
small function inside. But it could be great to group the syscalls by
categories, or so. For example, putting all POSIX compliant syscalls in
a single file and using a syscall table could make quite easy to develop
a BSD-user target (I did this in the past, not in Qemu though...). POSIX
compliant interfaces can mostly be shared with Linux ones and a lot of
other syscalls are common to the 3 BSD flavors (Net, Open and Free..).
Being able to add a BSD target sharing the same code would be a proof
the code is flexible and well organized; I guess large parts of the
Darwin user target could also be merged with a FreeBSD user target...

Just my few cents ideas, don't say it has to be implemented soon, just
think keeping those long-term goals in mind may help having a flexible
and clean implementation...

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[Thayne Harbaugh]

On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote:
> On Sat, 2007-11-03 at 01:21 +0000, Thiemo Seufer wrote:
> > Thayne Harbaugh wrote:
> > > There are several things that I'd like to see addressed in linux-user.
> > > Some of these are to fix bugs, some are to make qemu linux-user more
> > > like the Linux kernel, some are to make the internal qemu interfaces
> > > more consistent.
> > > 
> > > An internal coding practice that is being addressed bit-by-bit is that
> > > of managing the interface between the host and the target.  Currently
> > > this is a bit sloppy and inconsistent (some of which I've contributed
> > > to).  There are examples of using target addresses for host pointers and
> > > host errnos for target errnos, using different types between target and
> > > host that don't sign-extend properly, as well as other things.  This
> > > causes compiler warnings to actual run-time bugs.  Currently I'm
> > > reviewing all of the linux-user code (mostly syscall.c) to fix these
> > > inconsistencies.  I will be writing developer documentation describing
> > > the coding practices that should govern the target/host interface and
> > > submitting patches for the fixes.
> > > 
> > > As obvious as it may seem I'll re-state that the linux-user emulation is
> > > emulating the Linux kernel (duh!).  There are portions of qemu
> > > linux-user that are even excerpted directly from the Linux kernel.
> > > Consequently it is useful for internal qemu data and functions to
> > > closely mimic the kernel for best code sharing.  There are also
> > > advantages to even structuring qemu directly and file organization in
> > > similar divisions, groupings and locations.  Some of this organization
> > > might lead to good division so that other user/kernel divisions are
> > > cleaner (different kernel versions, other OSes - darwin-user and
> > > others).
> > > 
> > > Internal qemu interfaces are consistent - except when they aren't.  This
> > > causes coding errors when passing target and host arguments or return
> > > codes.  I'll be documenting the coding practices as well as submitting
> > > patches to make these consistent.  (That sounds a bit redundant with
> > > other things I've mentioned).
> > > 
> > > I have about 40 patches already worked up that do this.  Some of those
> > > patches might be broken up smaller.  The qemu that we've been working
> > > with is nearly rock solid (still a few more bugs being wrung out).  It
> > > can nearly build an entire Debian arm distribution for an arm target
> > > being hosted on x86_64.  We're quite excited to get our patches upstream
> > > so that others can benefit and to ease our maintenance overhead.  We're
> > > also turning our focus to PPC and other archs.
> > > 
> > > Please let me know if you support the general idea of the coding changes
> > > above: General clean-up, consistent target/host interfaces, file
> > > splitting/reorganizing, etc..  In the meantime I'll be putting together
> > > the developer documentation/coding guidelines for review.
> > 
> > FWIW, I agree with everything you said above.
> 
> I agree too.
> Code cleanup and sanitization is needed there.
> I'm just reserved about the code splitting point: as for the vl.h
> splitting, it should not lead to get files with only a single or two
> small function inside.

Right now I have it split similar to the Linux kernel.  It has
reasonable code grouping and makes it easy to compare code with the
kernel.

>  But it could be great to group the syscalls by
> categories, or so. For example, putting all POSIX compliant syscalls in
> a single file and using a syscall table could make quite easy to develop
> a BSD-user target (I did this in the past, not in Qemu though...). POSIX
> compliant interfaces can mostly be shared with Linux ones and a lot of
> other syscalls are common to the 3 BSD flavors (Net, Open and Free..).
> Being able to add a BSD target sharing the same code would be a proof
> the code is flexible and well organized; I guess large parts of the
> Darwin user target could also be merged with a FreeBSD user target...

That's a reasonable strategy as well.  I've looked through some of the
darwin code and have considered how common code could be merged.

> Just my few cents ideas, don't say it has to be implemented soon, just
> think keeping those long-term goals in mind may help having a flexible
> and clean implementation...

It's likely closer than you realize. 8-)

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[Fabrice Bellard]

Thayne Harbaugh wrote:
> On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote:
>> On Sat, 2007-11-03 at 01:21 +0000, Thiemo Seufer wrote:
>> [...]
>>  But it could be great to group the syscalls by
>> categories, or so. For example, putting all POSIX compliant syscalls in
>> a single file and using a syscall table could make quite easy to develop
>> a BSD-user target (I did this in the past, not in Qemu though...). POSIX
>> compliant interfaces can mostly be shared with Linux ones and a lot of
>> other syscalls are common to the 3 BSD flavors (Net, Open and Free..).
>> Being able to add a BSD target sharing the same code would be a proof
>> the code is flexible and well organized; I guess large parts of the
>> Darwin user target could also be merged with a FreeBSD user target...
> 
> That's a reasonable strategy as well.  I've looked through some of the
> darwin code and have considered how common code could be merged.

I am strongly against such merges.

Different OS emulation must be handled in different directories (and
maybe even in different projects) as they are likely to have subtle
differences which makes impossible to test a modification made for one
OS without testing all the other OSes.

Regards,

Fabrice.

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[Thayne Harbaugh]

On Sat, 2007-11-03 at 20:13 +0100, Fabrice Bellard wrote:
> Thayne Harbaugh wrote:
> > On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote:
> >> On Sat, 2007-11-03 at 01:21 +0000, Thiemo Seufer wrote:
> >> [...]
> >>  But it could be great to group the syscalls by
> >> categories, or so. For example, putting all POSIX compliant syscalls in
> >> a single file and using a syscall table could make quite easy to develop
> >> a BSD-user target (I did this in the past, not in Qemu though...). POSIX
> >> compliant interfaces can mostly be shared with Linux ones and a lot of
> >> other syscalls are common to the 3 BSD flavors (Net, Open and Free..).
> >> Being able to add a BSD target sharing the same code would be a proof
> >> the code is flexible and well organized; I guess large parts of the
> >> Darwin user target could also be merged with a FreeBSD user target...
> > 
> > That's a reasonable strategy as well.  I've looked through some of the
> > darwin code and have considered how common code could be merged.
> 
> I am strongly against such merges.
> 
> Different OS emulation must be handled in different directories (and
> maybe even in different projects) as they are likely to have subtle
> differences which makes impossible to test a modification made for one
> OS without testing all the other OSes.

Agreed.

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[J. Mayer]

On Sat, 2007-11-03 at 19:16 -0600, Thayne Harbaugh wrote:
> On Sat, 2007-11-03 at 20:13 +0100, Fabrice Bellard wrote:
> > Thayne Harbaugh wrote:
> > > On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote:
> > >> On Sat, 2007-11-03 at 01:21 +0000, Thiemo Seufer wrote:
> > >> [...]
> > >>  But it could be great to group the syscalls by
> > >> categories, or so. For example, putting all POSIX compliant syscalls in
> > >> a single file and using a syscall table could make quite easy to develop
> > >> a BSD-user target (I did this in the past, not in Qemu though...). POSIX
> > >> compliant interfaces can mostly be shared with Linux ones and a lot of
> > >> other syscalls are common to the 3 BSD flavors (Net, Open and Free..).
> > >> Being able to add a BSD target sharing the same code would be a proof
> > >> the code is flexible and well organized; I guess large parts of the
> > >> Darwin user target could also be merged with a FreeBSD user target...
> > > 
> > > That's a reasonable strategy as well.  I've looked through some of the
> > > darwin code and have considered how common code could be merged.
> > 
> > I am strongly against such merges.
> > 
> > Different OS emulation must be handled in different directories (and
> > maybe even in different projects) as they are likely to have subtle
> > differences which makes impossible to test a modification made for one
> > OS without testing all the other OSes.
> 
> Agreed.

If you take a close look, you'll find more variations between Linux ABIs
for different CPUs than between all BSD implementations: common syscalls
of all BSD flavors do the same thing (and have the same ABI whatever the
CPU...). You'll also find very few variations between the syscalls
common to BSD & Linux because most of those directly map POSIX defined
functions.
Then, following the given argument, we never should try to share any
code between linux-user for different targets, as the Linux ABI and
behavior is different for different CPUs...

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[Paul Brook]

> If you take a close look, you'll find more variations between Linux ABIs
> for different CPUs than between all BSD implementations: common syscalls
> of all BSD flavors do the same thing (and have the same ABI whatever the
> CPU...). You'll also find very few variations between the syscalls
> common to BSD & Linux because most of those directly map POSIX defined
> functions.
> Then, following the given argument, we never should try to share any
> code between linux-user for different targets, as the Linux ABI and
> behavior is different for different CPUs...

I'd guess that the ones that are all the same are the ones that don't take any 
real effort to implement in the first place.

If you can combine the implementations I'd also expect to be able to do cross 
emulation. e.g. run *BSD applications on a Linux host. This definitely works 
for simple cases, even in the extreme case of a windows host - as you say 
many syscalls map directly onto POSIX functions so there is only ever one 
implementation. Whether it works well enough for real applications or whole 
distributions of software I'm not so sure. If you can't do cross emulation 
I'm sceptical about how much they can be combined.

Paul

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[J. Mayer]

On Sun, 2007-11-04 at 01:51 +0000, Paul Brook wrote:
> > If you take a close look, you'll find more variations between Linux ABIs
> > for different CPUs than between all BSD implementations: common syscalls
> > of all BSD flavors do the same thing (and have the same ABI whatever the
> > CPU...). You'll also find very few variations between the syscalls
> > common to BSD & Linux because most of those directly map POSIX defined
> > functions.
> > Then, following the given argument, we never should try to share any
> > code between linux-user for different targets, as the Linux ABI and
> > behavior is different for different CPUs...
> 
> I'd guess that the ones that are all the same are the ones that don't take any 
> real effort to implement in the first place.
> 
> If you can combine the implementations I'd also expect to be able to do cross 
> emulation. e.g. run *BSD applications on a Linux host. This definitely works 
> for simple cases, even in the extreme case of a windows host - as you say 
> many syscalls map directly onto POSIX functions so there is only ever one 
> implementation. Whether it works well enough for real applications or whole 
> distributions of software I'm not so sure. If you can't do cross emulation 
> I'm sceptical about how much they can be combined.

Ooops... I should have been more precise. In my idea, it was
"BSD-on-Linux" I was talking about. Let's say OpenBSD / NetBSD. FreeBSD
has some specific tricks that might be difficult to map on Linux (or
even other BSD), not even talking of Darwin which is quite impossible to
emulate (or if one wants to emulate the IOkit...). The main difficulty
of emulating BSD on Linux is the sysctl syscall, the trace facilites and
the ioctls. I guess we can forget the ioctls... Most of the other
syscalls mappings are quite like mapping one Linux port to another.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)

[TJ]

I'm glad you posted about your efforts since I've also been working on
solving related x86_64 build warnings caused by 32-bit int to 64-bit
pointer conversions. 

warning: cast to pointer from integer of different size

There are a lot of these in syscall.c

I have in my drafts folder an RFC I was planning to post detailing the
issue (1,053 warnings in the x64_64 build) and how to resolve them -
some simply require a cast from abi_long/unit32_t to a larger integer
storage (same size as host-pointer-size) using the various pre-processor
macros and typedefs so the compiler can do implicit conversion from the
larger integer type to the pointer.

I'll post what I've written so far so it can be considered in
conjunction with your work.

The title is "RFC: x86_64 Best way to fix 'cast to pointer from integer
of different size' problems?"

TJ.