Re: [RFC v7 00/22] i386 cleanup [hw/core/cpu.c common]

[Eduardo Habkost]

On Fri, Dec 04, 2020 at 05:07:21PM +0100, Paolo Bonzini wrote:
> Il ven 4 dic 2020, 14:54 Claudio Fontana <cfontana@suse.de> ha scritto:
> 
> > On 11/30/20 3:35 AM, Claudio Fontana wrote:
> > > Hi all, this is v7 of the i386 cleanup,
> >
> > This is fairly broken still and I am fixing it up,
> >
> > but a question arises while hunting bugs here.
> >
> > Silent bugs are introduced when trying to use code like
> >
> > #ifndef CONFIG_USER_ONLY
> >
> > in files that are built in "common" objects, since they are target
> > independent.
> >
> 
> That should be avoided by poison.h
> 
> I wonder also about the rationale why the cpu code is split between
> >
> > hw/core/cpu.c and $(top_srcdir)/cpu.c
> >
> > with one part in common and one part in "target specific".
> >
> 
> Mostly historical, cpu.c used to have much more than CPU code (it was
> exec.c until a month ago, one of the "historical" core files in QEMU and it
> had all the dispatch side of the memory API). I wouldn't mind merging these
> two files into one.
> 
> Paolo
> 
> 
> > What do we gain by having part of the cpu in common?
> >
> > In some cases we end up going through all sort of hoops because we cannot
> > just code everything in hw/core/cpu.c due to the fact
> > that we do not see CONFIG_ there.
> >

I really prefer to have core files guaranteed to be generic, so
we don't risk introducing additional per-target differences in
base QOM classes (including TYPE_CPU).

The hoops we are having to go through are hoops we must go
through if we want a multi-architecture QEMU binary in the
future.  We don't need to fix everything at once (that's why
$(top_srcdir)/cpu.c still exists), but we don't need to make this
harder.

-- 
Eduardo