> If this is the case, it means we don't need anything complicated. Devices
> map themselves straight into the system address space at the appropriate
> slot address (no plug-n-play to worry about), and device "DMA" goes via the
> IOMMU.
Further searching by google suggests I may be wrong.
The al
Alexander Graf wrote:
Hi,
I'm still trying to implement SVM correctly and hit a serious problem.
If I set CC_OP to EFLAGS / DYNAMIC after each instruction (so most
conditional operations are based on EFLAGS) everything works as expected.
If using CC_OP==CC_OP_EFLAGS only CC_SRC should be used an
> This is a bit mysterious for me too. SBus address space is 28 bits
> (256MB). Usually each slot maps to a different area. So the CPU sees
> one slot for example at 0x3000 and other at 0x4000 .
>
> IOMMU can map max 2G of memory, usually a 32 or 64MB region. For the
> devices, this device
On 8/29/07, Johannes Schindelin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Wed, 29 Aug 2007, Michael Matz wrote:
>
> > On Wed, 29 Aug 2007, Johannes Schindelin wrote:
> >
> > > > Thanks for your effor Michael! Now, I only hope, one of the patches
> > > > that makes qemu gcc4 compliant are soon merged.
On Tue, 2007-08-28 at 21:57 +0200, Michael Matz wrote:
> Hi,
>
> [please keep me CCed, I'm not on this list]
>
> the below patch let's qemu be compiled by GCC 4.2 (probably also 4.1 and
> others) for most hosts (i386,x86_64,ia64,ppc). s390 as host is missing,
> and needs a compiler change to e
Hi,
On Wed, 29 Aug 2007, Paul Brook wrote:
> >I solved that by placing one of the T[012] operands into memory
> >for HOST_I386, thereby freeing one reg. Here's some justification
> >of why that doesn't really cost performance: with three free regs
> >GCC is alread
On 8/28/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > On second thought, there is a huge difference between a write access
> > originating from CPU destined for the device and the device writing to
> > main memory. The CPU address could be 0xf000 1000, which may translate
> > to a bus address of 0x
Hi,
On Wed, 29 Aug 2007, Michael Matz wrote:
> On Wed, 29 Aug 2007, Johannes Schindelin wrote:
>
> > > Thanks for your effor Michael! Now, I only hope, one of the patches
> > > that makes qemu gcc4 compliant are soon merged.
> >
> > Well, to throw a spanner in the works: this patch is the 4th
Hi,
On Wed, 29 Aug 2007, Johannes Schindelin wrote:
> > Thanks for your effor Michael! Now, I only hope, one of the patches
> > that makes qemu gcc4 compliant are soon merged.
>
> Well, to throw a spanner in the works: this patch is the 4th patch along
> the lines that I came about. None of t
Hi,
I'm still trying to implement SVM correctly and hit a serious problem.
If I set CC_OP to EFLAGS / DYNAMIC after each instruction (so most
conditional operations are based on EFLAGS) everything works as expected.
If using CC_OP==CC_OP_EFLAGS only CC_SRC should be used and CC_DST is
supposed to
On Wed, 29 Aug 2007, Alexander Graf wrote:
Paul Jakma wrote:
I think that's unlikely, and it'd be nice if QEMU by default did a
fcntl() on writeable image files to lock itself from multiple access,
I'm usually running one "main" qemu instance that has rea
Paul Jakma wrote:
> On Mon, 27 Aug 2007, Anthony Liguori wrote:
>
>> I think this is the right level myself. Advisory locks work okay but
>> not all filesystems support them. It's particularly nasty when you have
>> a clustered filesystem in the host. I think it would do more harm than
>> good t
>I solved that by placing one of the T[012] operands into memory
>for HOST_I386, thereby freeing one reg. Here's some justification
>of why that doesn't really cost performance: with three free regs
>GCC is already spilling like mad in the snippets, we just trade on
On Mon, 27 Aug 2007, Anthony Liguori wrote:
I think this is the right level myself. Advisory locks work okay but
not all filesystems support them. It's particularly nasty when you have
a clustered filesystem in the host. I think it would do more harm than
good to have a feature like that was
Am 29.08.2007 um 16:19 schrieb Johannes Schindelin:
I referred to previous patches, specifically those currently
applied
for Q: http://www.kju-app.org/proj/browser/trunk/patches
I'll try to put them on my repo.or.cz repository, too.
Note that from briefly looking at them they appear to co
Hi,
Am 29.08.2007 um 15:59 schrieb Johannes Schindelin:
I referred to previous patches, specifically those currently
applied for
Q: http://www.kju-app.org/proj/browser/trunk/patches
Is there _any_ way to get at the raw diffs instead of some @!%!
marked up
HTML abomination that cannot be
Hi,
On Wed, 29 Aug 2007, Ronald wrote:
> Johannes Schindelin schreef:
>
> > On Wed, 29 Aug 2007, Andreas F?rber wrote:
> >
> > > I referred to previous patches, specifically those currently applied
> > > for Q: http://www.kju-app.org/proj/browser/trunk/patches
> >
> > Is there _any_ way to
Johannes Schindelin schreef:
Hi,
On Wed, 29 Aug 2007, Andreas F?rber wrote:
I referred to previous patches, specifically those currently applied for
Q: http://www.kju-app.org/proj/browser/trunk/patches
Is there _any_ way to get at the raw diffs instead of some @!%! marked up
HTML ab
Hi,
On Wed, 29 Aug 2007, Mulyadi Santosa wrote:
> Thanks for your effor Michael! Now, I only hope, one of the patches that
> makes qemu gcc4 compliant are soon merged.
Well, to throw a spanner in the works: this patch is the 4th patch along
the lines that I came about. None of them (AFAICT) wa
Hi ...
Thanks for your effor Michael! Now, I only hope, one of the patches that
makes qemu gcc4 compliant are soon merged. Or, is there any plan to
merge qops?
regards,
Mulyadi
Hi,
On Wed, 29 Aug 2007, Andreas F?rber wrote:
> I referred to previous patches, specifically those currently applied for
> Q: http://www.kju-app.org/proj/browser/trunk/patches
Is there _any_ way to get at the raw diffs instead of some @!%! marked up
HTML abomination that cannot be applied?
C
Hi,
On Wed, 29 Aug 2007, Andreas Färber wrote:
> > >What do you mean with 0.9.0-cvs? The 0.9.0 GCC4 patches for OSX/Intel
> >
> >Do you mean my patches?
>
> No. Are yours already OSX-compatible?
No OSX, no idea :)
> I referred to previous patches, specifically those currently applied for
> Q:
Am 29.08.2007 um 13:40 schrieb Michael Matz:
The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex
might know the exact checkout date), so chances are that it still
applies :)
What do you mean with 0.9.0-cvs? The 0.9.0 GCC4 patches for OSX/Intel
Do you mean my patches?
No.
[EMAIL PROTECTED] wrote on 08/28/2007
04:13:02 AM:
> Anthony Liguori wrote:
> >> In the scenario you mention, libvirt should probably do a sanity
check for
> >> this before letting you start the guest. libvirt already supports the
idea
> >> of 'shared' disk images where two or more guests can b
Hi,
On Wed, 29 Aug 2007, Michael Matz wrote:
> On Wed, 29 Aug 2007, Johannes Schindelin wrote:
>
> > > The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex
> > > might know the exact checkout date), so chances are that it still
> > > applies :)
> >
> > It is based on the z80 f
Hi,
On Wed, 29 Aug 2007, Johannes Schindelin wrote:
> > The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex
> > might know the exact checkout date), so chances are that it still
> > applies :)
>
> It is based on the z80 fork, but it applies relatively cleanly (one
> trailing
Hi,
On Wed, 29 Aug 2007, Andreas Färber wrote:
> Am I right to assume that compiling with gcc3 will still work with your
> patch?
Yes.
> In that case your patch would enable qemu to run on gcc4-only platforms
> (where performance doesn't matter too much yet) while allowing to
> compile with
Hi,
On Tue, 28 Aug 2007, Michael Matz wrote:
> The whole patch is against a 0.9.0-cvs version from 2007-07-09 (Alex
> might know the exact checkout date), so chances are that it still
> applies :)
It is based on the z80 fork, but it applies relatively cleanly (one
trailing whitespace) to the
Hi Michael,
Am 28.08.2007 um 21:57 schrieb Michael Matz:
the below patch let's qemu be compiled by GCC 4.2
Thanks for your effort!
Here's some justification
of why that doesn't really cost performance: with three free
regs
GCC is already spilling like mad in the snippets, we
29 matches
Mail list logo
