[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

How would you avoid the compilation of all the
> unnecessary emulated devices?

Device config files.

Regards,

Anthony Liguori

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.