On Wed, 2007-09-19 at 16:35 +0100, Paul Brook wrote:
> > > >> OK, great. Having 64 bits may also help for additional (ie future...)
> > > >> features in PowerPC 64 emulation.
> > > >
> > > > Maybe worth letting the target say whether it needs 32 or 64-bit
> > > > flags.
> > > > The flag lookup is l
> > >> OK, great. Having 64 bits may also help for additional (ie future...)
> > >> features in PowerPC 64 emulation.
> > >
> > > Maybe worth letting the target say whether it needs 32 or 64-bit
> > > flags.
> > > The flag lookup is likely to be on a hot path.
> > >
>
> I may be wrong, but it seems
On Sep 19, 2007, at 4:39 PM, Jocelyn Mayer wrote:
On Wed, 2007-09-19 at 12:56 +0200, Alexander Graf wrote:
On Sep 19, 2007, at 1:28 AM, Paul Brook wrote:
Ok, I will try to shift the intercepts in an uint_64 flags
variable
in the TB.
OK, great. Having 64 bits may also help for additional
On Wed, 2007-09-19 at 12:56 +0200, Alexander Graf wrote:
> On Sep 19, 2007, at 1:28 AM, Paul Brook wrote:
>
> Ok, I will try to shift the intercepts in an uint_64 flags variable
> in the TB.
> >>
> >> OK, great. Having 64 bits may also help for additional (ie future...)
> >> features in
flags64.patch
Description: Binary data
On Sep 19, 2007, at 1:28 AM, Paul Brook wrote:
Ok, I will try to shift the intercepts in an uint_64 flags variable
in the TB.
OK, great. Having 64 bits may also help for additional (ie future...)
features in PowerPC 64 emulation.
Maybe worth letting
On Sep 19, 2007, at 1:28 AM, Paul Brook wrote:
Ok, I will try to shift the intercepts in an uint_64 flags variable
in the TB.
OK, great. Having 64 bits may also help for additional (ie future...)
features in PowerPC 64 emulation.
Maybe worth letting the target say whether it needs 32 or 64-
> > > Ok, I will try to shift the intercepts in an uint_64 flags variable
> > > in the TB.
>
> OK, great. Having 64 bits may also help for additional (ie future...)
> features in PowerPC 64 emulation.
Maybe worth letting the target say whether it needs 32 or 64-bit flags.
The flag lookup is likely
On Tue, 2007-09-18 at 22:54 +0200, J. Mayer wrote:
> Forwarded, as requested.
>
> Forwarded Message
> > From: Alexander Graf <[EMAIL PROTECTED]>
> > To: J.Mayer <[EMAIL PROTECTED]>
> > Subject: Re: [Qemu-devel] [PATCH] SVM support
&g
Forwarded, as requested.
Forwarded Message
> From: Alexander Graf <[EMAIL PROTECTED]>
> To: J.Mayer <[EMAIL PROTECTED]>
> Subject: Re: [Qemu-devel] [PATCH] SVM support
> Date: Tue, 18 Sep 2007 13:51:26 +0200
>
> On Sep 18, 2007, at 12:09 PM, J. Ma
On 9/18/07, J. Mayer <[EMAIL PROTECTED]> wrote:
> Going this way, I see no reason why the interruption code in the cpu_exec loop
> could not finally become:
> interrupt_request = env->interrupt_request;
> if (__builtin_expect(interrupt_request, 0)) {
>
On Tue, 2007-09-18 at 03:02 +0200, Alexander Graf wrote:
> Jocelyn Mayer wrote:
> > On Mon, 2007-09-17 at 12:02 +0200, Alexander Graf wrote:
> >
> >> J. Mayer wrote:
> >>
> >>> On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
> >>>
> >>>
> Thiemo Seufer wrote:
>
Alexander Graf wrote:
> Jocelyn Mayer wrote:
>
>>>
>>> I don't see any practical reason not to do it this way. We could define
>>> a CPU_INTERRUPT_TARGET interrupt, that stores the information in a the
>>> target specific CPUState, but this would hit performance (marginally
>>> though) and does
Jocelyn Mayer wrote:
> On Mon, 2007-09-17 at 12:02 +0200, Alexander Graf wrote:
>
>> J. Mayer wrote:
>>
>>> On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
>>>
>>>
Thiemo Seufer wrote:
> Alexander Graf wrote:
>
>
>
On Mon, 2007-09-17 at 12:02 +0200, Alexander Graf wrote:
> J. Mayer wrote:
> > On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
> >
> >> Thiemo Seufer wrote:
> >>
> >>> Alexander Graf wrote:
> >>>
> >>>
> Thanks to Michael Peter who tried the patch on an x86 host I fo
J. Mayer wrote:
> On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
>
>> Thiemo Seufer wrote:
>>
>>> Alexander Graf wrote:
>>>
>>>
Thanks to Michael Peter who tried the patch on an x86 host I found some
compilation problems.
This updated patch addresses these
On Thu, 2007-09-13 at 17:27 +0200, Alexander Graf wrote:
> Thiemo Seufer wrote:
> > Alexander Graf wrote:
> >
> >> Thanks to Michael Peter who tried the patch on an x86 host I found some
> >> compilation problems.
> >> This updated patch addresses these issues and thus should compile on
> >> eve
Alexander Graf wrote:
> Thanks to Michael Peter who tried the patch on an x86 host I found some
> compilation problems.
> This updated patch addresses these issues and thus should compile on
> every platform for every target available.
Tried that on PPC/Linux:
libqemu.a(cpu-exec.o): In function c
On Thu, Aug 30, 2007 at 04:54:15PM +0200, Alexander Graf wrote:
> Hi,
>
> after a lot of struggling I finally got everything working smoothly
> (special thanks to Fabrice and Avi), so I believe this patch is ready to
> be taken upstream.
> CC_DST was never a problem, as everything I did in the efl
18 matches
Mail list logo
