Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible

[Stefano Stabellini]

On Mon, 6 Jan 2014, Anthony Liguori wrote:
> On Mon, Jan 6, 2014 at 7:57 AM, Stefano Stabellini
> <address@hidden> wrote:
> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> >> On Jan 6, 2014 6:55 AM, "Stefano Stabellini" <address@hidden> wrote:
> >> >
> >> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> >> > > On Jan 6, 2014 6:23 AM, "Peter Maydell" <address@hidden> wrote:
> >> > > >
> >> > > > On 6 January 2014 14:17, Stefano Stabellini
> >> > > > <address@hidden> wrote:
> >> > > > > It doesn't do any emulation so it is not specific to any 
> >> > > > > architecture or
> >> > > > > any cpu.
> >> > > >
> >> > > > You presumably still care about the compiled in values of
> >> > > > TARGET_WORDS_BIGENDIAN, TARGET_LONG_SIZE, and so on...
> >> >
> >> > Actually it only uses XC_PAGE_SIZE and the endianness is the host
> >> > endianness.
> >>
> >> If blkif in QEMU is relying on host endianness thats a bug.
> >
> > Why? Xen doesn't support a different guest/host endianness.
> 
> For the same reason that the virtio devices do not rely on host endianness.
> 
> It should be possible to use the Xen devices with TCG.  It isn't today
> simply because the code wasn't structured that way but it could be
> refactored to do this.
> 
> >> > > Yup.  It's still accel=xen just with no VCPUs.
> >> >
> >> > Are you talking about introducing accel=xen to Wei's target-null?
> >> > I guess that would work OK.
> >>
> >> We already have accel=xen.  I'm echoing Peter's suggestion of having the 
> >> ability to compile out accel=tcg.
> >>
> >> >
> >> > On the other hand if you are thinking of avoiding the introduction of a
> >> > new target-null, how would you make xen_machine_pv.c available to
> >> > multiple architectures?
> >>
> >> Why does qdisk need a full machine?
> >
> > qdisk is just one device, xen_machine_pv is the machine that initializes
> > the backend infrastructure (one of the backends is qdisk).
> > It doesn't make sense to use a full-blown machine like pc.c just to
> > start few backends, right?
> 
> What prevents xen_machine_pv from being compiled for multiple targets?
>  If there i386 specific things in it, they surely could be refactored
> a bit, no?

Not at all, but I thought that at the moment one machine has to be tied
to one architecture. If I am wrong, then there is no issue.