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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 6 Jan 2014, Anthony Liguori wrote:
> On Jan 6, 2014 6:55 AM, "Stefano Stabellini" 
> <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> >
> > On Mon, 6 Jan 2014, Anthony Liguori wrote:
> > > On Jan 6, 2014 6:23 AM, "Peter Maydell" <peter.maydell@xxxxxxxxxx> wrote:
> > > >
> > > > On 6 January 2014 14:17, Stefano Stabellini
> > > > <stefano.stabellini@xxxxxxxxxxxxx> 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.


> > > 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?


> How would you avoid the compilation of all the
> > unnecessary emulated devices?
> 
> Device config files.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel