Anthony Liguori wrote:
>
>> In the short term we'll have to fork a working userspace, since we're in
>> the middle of some other stuff (such as real guest IO, which I think is
>> pretty important :) .
>>
>> Long term, one option is to try to define a new qemu target that
>> completely bypasses the
Hollis Blanchard wrote:
> On Tue, 2008-02-12 at 12:45 +0200, Avi Kivity wrote:
>
>> Hollis Blanchard wrote:
>>
>>> Long term, one option is to try to define a new qemu target that
>>> completely bypasses the code generation parts of qemu. Anthony did that
>>> for x86 once, but there are at
On Tue, 2008-02-12 at 12:45 +0200, Avi Kivity wrote:
> Hollis Blanchard wrote:
> > Long term, one option is to try to define a new qemu target that
> > completely bypasses the code generation parts of qemu. Anthony did that
> > for x86 once, but there are at least a couple sticking points; not sure
Hollis Blanchard wrote:
> Hi Avi, we're having a problem with the qemu merge you just did in
> kvm-userspace.
>
> Upstream qemu recently added the TCG code generator to phase out dyngen.
> When he did that, Fabrice explicitly broke the build every non-x86
> architecture, and since you've now pulled
Hollis Blanchard wrote:
> Hi Avi, we're having a problem with the qemu merge you just did in
> kvm-userspace.
>
> Upstream qemu recently added the TCG code generator to phase out dyngen.
> When he did that, Fabrice explicitly broke the build every non-x86
> architecture, and since you've now pulled
Hi Avi, we're having a problem with the qemu merge you just did in
kvm-userspace.
Upstream qemu recently added the TCG code generator to phase out dyngen.
When he did that, Fabrice explicitly broke the build every non-x86
architecture, and since you've now pulled that breakage into KVM, we're
stuc
