[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: |
Wei Liu |
Subject: |
Re: [Qemu-devel] [PATCH RFC 0/5] Xen: introduce Xen PV target |
Date: |
Fri, 24 Jan 2014 14:50:09 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Jan 24, 2014 at 03:38:01PM +0100, Paolo Bonzini wrote:
> 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
>
Correct... What I really meant was "those virtualization solutions don't
care much about CPU emulation" (if there's any other than Xen).
> (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.
>
OK, good to know.
> (3) there's a precedent for supporting different guests between the
> guest and the host in blkback, you can do the same for endianness.
>
Yes. But this is still open question at the moment, as there's no
canonical protocol for this (it hasn't even been discussed).
Your second point is the thing I missed though. Thanks for reminding.
Wei.
> Paolo
- [Qemu-devel] [PATCH RFC 4/5] xen: implement Xen PV target, (continued)
- [Qemu-devel] [PATCH RFC 4/5] xen: implement Xen PV target, Wei Liu, 2014/01/23
- [Qemu-devel] [PATCH RFC 2/5] xen: factor out common functions, Wei Liu, 2014/01/23
- [Qemu-devel] [PATCH RFC 1/5] xen: move Xen PV machine files to hw/xenpv, Wei Liu, 2014/01/23
- [Qemu-devel] [PATCH RFC 3/5] exec: guard Xen HVM hooks with CONFIG_XEN_I386, Wei Liu, 2014/01/23
- [Qemu-devel] [PATCH RFC 5/5] xen: introduce xenpv-softmmu.mak, Wei Liu, 2014/01/23
- Re: [Qemu-devel] [PATCH RFC 0/5] Xen: introduce Xen PV target, Peter Maydell, 2014/01/23
- Re: [Qemu-devel] [PATCH RFC 0/5] Xen: introduce Xen PV target, Paolo Bonzini, 2014/01/24
Re: [Qemu-devel] [PATCH RFC 0/5] Xen: introduce Xen PV target, Paolo Bonzini, 2014/01/24