qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC 0/5] Xen: introduce Xen PV target


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH RFC 0/5] Xen: introduce Xen PV target
Date: Fri, 24 Jan 2014 15:38:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Il 24/01/2014 15:23, Wei Liu ha scritto:
On Thu, Jan 23, 2014 at 10:30:16PM +0000, Peter Maydell wrote:
On 23 January 2014 22:16, Wei Liu <address@hidden> wrote:
As promised I hacked a prototype based on Paolo's disable TCG series.
However I coded some stubs for TCG anyway. So this series in principle
should work with / without Paolo's series.

I'm afraid I still think this is a terrible idea. "Xen" isn't a CPU, and

Thanks for being blunt. ;-)

"the binary is smaller" isn't IMHO sufficient justification for breaking
QEMU's basic structure of "target-* define target CPUs and we have
a lot of compile time constants which are specific to a CPU which
get defined there". How would you support a bigendian Xen CPU,
just to pick one example of where this falls down?


I think about this deeper. From Xen's (and I speculate this applies to
other hardware assisted virtulization solution as well) PoV only the
native endianess is supported, does it make sense to have a
target-native thing?

I think this is wrong, for a few reasons:

(1) xenpv is not hardware assisted virtualization

(2) supporting only native endianness leads to complications when systems are bi-endian, as is the case for PPC. For example, virtio 1.0 will always be little endian.

(3) there's a precedent for supporting different guests between the guest and the host in blkback, you can do the same for endianness.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]