malc writes:
> On Sat, 5 Dec 2009, Markus Armbruster wrote:
>
>> Anthony Liguori writes:
>>
>> > Markus Armbruster wrote:
>> >> Commit a7d27b53 made zero-sized allocations a fatal error, deviating
>> >> from ISO C's malloc() & friends. Revert that, but take care never to
>> >> return a null po
On Sun, 6 Dec 2009, Andreas F?rber wrote:
>
> Am 06.12.2009 um 06:14 schrieb malc:
>
> > On Sun, 6 Dec 2009, Andreas Faerber wrote:
> >
> > > qemu-system-sparc64 works on ppc64 while it didn't on ppc!
> >
> > Does it work on linux ppc64? If so
>
> Haven't had a chance to test on other ppc[64]
On Sun, 6 Dec 2009, Andreas F?rber wrote:
>
> Am 06.12.2009 um 06:13 schrieb malc:
>
> > On Sun, 6 Dec 2009, Andreas Faerber wrote:
> >
> > > Darwin/ppc64 does not use function descriptors,
> > > adapt prologue and tcg_out_call accordingly.
> > > GPR2 is available for general use, so let's use
Am 06.12.2009 um 06:14 schrieb malc:
On Sun, 6 Dec 2009, Andreas Faerber wrote:
qemu-system-sparc64 works on ppc64 while it didn't on ppc!
Does it work on linux ppc64? If so
Haven't had a chance to test on other ppc[64] platforms yet.
how exactly did you test that
(so that i can try to
Am 06.12.2009 um 06:13 schrieb malc:
On Sun, 6 Dec 2009, Andreas Faerber wrote:
Darwin/ppc64 does not use function descriptors,
adapt prologue and tcg_out_call accordingly.
GPR2 is available for general use, so let's use it.
http://developer.apple.com/mac/library/documentation/DeveloperTools
On Sun, 6 Dec 2009, Andreas Faerber wrote:
> Hello,
>
> This mini series adds TCG target support for OSX/ppc64
> and fixes the Cocoa frontend for ppc64.
>
> With these patches applied, qemu and qemu-system-x86_64
> are usable. Tested on Mac OS X v10.5 with a Haiku disk image
> and a Fedora 12 in
On Sun, 6 Dec 2009, Andreas Faerber wrote:
> Darwin/ppc64 does not use function descriptors,
> adapt prologue and tcg_out_call accordingly.
> GPR2 is available for general use, so let's use it.
>
> http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/LowLevelABI/110-64-b
Darwin/ppc64 does not use function descriptors,
adapt prologue and tcg_out_call accordingly.
GPR2 is available for general use, so let's use it.
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/LowLevelABI/110-64-bit_PowerPC_Function_Calling_Conventions/64bitPowerPC.h
Missing static for cocoa_keycode_to_qemu.
Missing const for character constant.
__LITTLE_ENDIAN__ is undefined on Big Endian host.
Signed-off-by: Andreas Faerber
Cc: John Arbuckle
---
cocoa.m |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cocoa.m b/cocoa.m
index
Fix integer usage in the Cocoa backend: NSInteger is long on LP64.
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html#//apple_ref/doc/uid/2014-BBCFHHCD
This makes the graphical display show up on a ppc64 host.
Signed
Hello,
This mini series adds TCG target support for OSX/ppc64
and fixes the Cocoa frontend for ppc64.
With these patches applied, qemu and qemu-system-x86_64
are usable. Tested on Mac OS X v10.5 with a Haiku disk image
and a Fedora 12 installation disk.
qemu-system-sparc works fine, too.
qemu-s
Avi Kivity wrote:
> It's not that it doesn't have a way to report failure, it's that it
> doesn't fail. Do you prefer functions that fail and report it to
> functions that don't fail?
You have a way of allocating memory that will _never_ fail?
>> Seriously, who does that anyway? why call malloc
On 12/06/2009 01:08 AM, Ian Molton wrote:
Avi Kivity wrote:
Only if you allocate using POSIX malloc(). If you allocate using a
function that is defined to return a valid pointer for zero length
allocations, you're happy.
Wouldnt it be better to, rather than use a qemu_malloc() that
Avi Kivity wrote:
> Only if you allocate using POSIX malloc(). If you allocate using a
> function that is defined to return a valid pointer for zero length
> allocations, you're happy.
Wouldnt it be better to, rather than use a qemu_malloc() that is utterly
counterintuitive in that it has no way
On 12/05/2009 10:58 PM, Anthony Liguori wrote:
Avi Kivity wrote:
When we see a lengthy and error prone idiom we usually provide a
wrapper. That wrapper is qemu_malloc(). If you like, don't see it
as a fixed malloc(), but as qemu's way of allocating memory which is
totally independent from ma
Ian Molton wrote:
> Anthony Liguori wrote:
>
> New patch attached, addressing the below. Thanks!
Did this patch make it? I cant seem to find my earlier patches in the
.git repo you mentioned, does that mean they have been dropped, or that
they have been merged upstream ?
I can repost all four pa
Avi Kivity wrote:
When we see a lengthy and error prone idiom we usually provide a
wrapper. That wrapper is qemu_malloc(). If you like, don't see it as
a fixed malloc(), but as qemu's way of allocating memory which is
totally independent from malloc().
We constantly get patches with qemu_ma
On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno wrote:
> On Thu, Dec 03, 2009 at 10:03:18PM +0200, Blue Swirl wrote:
>> On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno wrote:
>> > On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
>> >> I've got all of the patches I'm considering for
On Thu, Dec 03, 2009 at 10:03:18PM +0200, Blue Swirl wrote:
> On Thu, Dec 3, 2009 at 9:26 PM, Aurelien Jarno wrote:
> > On Wed, Dec 02, 2009 at 10:46:11AM -0600, Anthony Liguori wrote:
> >> I've got all of the patches I'm considering for 0.12 currently in
> >> staging. I'm going to work through a
On Sat, Dec 05, 2009 at 08:08:27PM +0300, malc wrote:
> ret = read (fd, p, 0);
> if (ret != 0) err (1, "read");
> return 0;
> }
> eof
> read$ ./a.out
> a.out: read: Bad address
>
> Even though that linux's read(2) man page claims [1]:
>
> DESCRIPTION
>
On Sat, Dec 5, 2009 at 6:44 PM, Avi Kivity wrote:
[...]
>
>> I think Laurent's proposal would work. We even could go so far as
>> rename the current function as qemu_malloc_possibly_broken (and adjust
>> callers mechanically) and introduce two new versions, which handle the
>> zero case in clearly
On 12/05/2009 07:54 PM, Anthony Liguori wrote:
Avi Kivity wrote:
A zero-supporting qemu_malloc() is fully compatible with malloc(),
we're only restricting the possible returns. So we're not misleading
any caller. In fact, taking your argument to the extreme, a malloc
implementation would nee
Avi Kivity wrote:
I think I made my point poorly. Consider the following:
qemu-img create -f raw base.img 10G
qemu-img create -f qcow2 -b base.img cow1.img
qemu-img create -f qcow2 -b base.img cow2.img
qemu -drive file=cow1.img,lock=exclusive
qemu -drive file=cow2.img,lock=exclusive
With the
On 12/05/2009 07:47 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 12/05/2009 12:29 AM, Anthony Liguori wrote:
Well disk sharing isn't actually bad as long as it's raw or a
physical device.
For qcow2, it's very complicated by backing files because we really
need to express the concept of
Avi Kivity wrote:
A zero-supporting qemu_malloc() is fully compatible with malloc(),
we're only restricting the possible returns. So we're not misleading
any caller. In fact, taking your argument to the extreme, a malloc
implementation would need to
This is really the crux of the whole argu
Avi Kivity wrote:
On 12/05/2009 12:29 AM, Anthony Liguori wrote:
Well disk sharing isn't actually bad as long as it's raw or a
physical device.
For qcow2, it's very complicated by backing files because we really
need to express the concept of a read-write lock.
That is, as long as the gue
On 12/05/2009 07:28 PM, Blue Swirl wrote:
On Sat, Dec 5, 2009 at 5:07 PM, Avi Kivity wrote:
On 12/04/2009 06:49 PM, Anthony Liguori wrote:
I still believe that it is poor practice to pass size==0 to *malloc(). I
think actively discouraging this in qemu is a good thing because it's a
On 12/05/2009 07:27 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 12/04/2009 06:49 PM, Anthony Liguori wrote:
I still believe that it is poor practice to pass size==0 to
*malloc(). I think actively discouraging this in qemu is a good
thing because it's a broken idiom.
Why? Unless we ha
On 12/05/2009 12:30 AM, Anthony Liguori wrote:
Paul Brook wrote:
On Monday 30 November 2009, Alexander Graf wrote:
Currently we have this stupid role of disallowing:
if (r)
break;
This has been discussed to death several times, in several different
paces, and with no clear resolutio
On 12/05/2009 12:29 AM, Anthony Liguori wrote:
Well disk sharing isn't actually bad as long as it's raw or a physical
device.
For qcow2, it's very complicated by backing files because we really
need to express the concept of a read-write lock.
That is, as long as the guests are opening the
On Sat, Dec 5, 2009 at 5:07 PM, Avi Kivity wrote:
> On 12/04/2009 06:49 PM, Anthony Liguori wrote:
>>
>> I still believe that it is poor practice to pass size==0 to *malloc(). I
>> think actively discouraging this in qemu is a good thing because it's a
>> broken idiom.
>
> Why? Unless we have a
Avi Kivity wrote:
On 12/04/2009 06:49 PM, Anthony Liguori wrote:
I still believe that it is poor practice to pass size==0 to
*malloc(). I think actively discouraging this in qemu is a good
thing because it's a broken idiom.
Why? Unless we have a separate array allocator (like C++'s new an
On 12/05/2009 07:08 PM, malc wrote:
What's the impact of such usage? What would improve for users if it
were eradicated? For developers?
I believe the answer the first two questions is "nothing in particular",
and the answer to the last one is "hassle". But I'd be happy to see
*specific* ex
On Sat, 5 Dec 2009, Markus Armbruster wrote:
> Anthony Liguori writes:
>
> > Markus Armbruster wrote:
> >> Commit a7d27b53 made zero-sized allocations a fatal error, deviating
> >> from ISO C's malloc() & friends. Revert that, but take care never to
> >> return a null pointer, like malloc() & f
On 12/04/2009 06:49 PM, Anthony Liguori wrote:
I still believe that it is poor practice to pass size==0 to
*malloc(). I think actively discouraging this in qemu is a good thing
because it's a broken idiom.
Why? Unless we have a separate array allocator (like C++'s new and
new[]), we need
I think OSX can be treated like Linux and BSD for the PTY handling.
Best regards
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg
On Fri, Dec 04, 2009 at 11:33:13AM +0100, Alexander Graf wrote:
> SeaBIOS needs to write to the f-segment. So it needs to have some way to set
> that from read-only to read-write, write in it and when it's done set it to
> read-only again.
>
> On PCI we have a mechanism for that. The ISA machine d
Hello,
probably a stupid remark, but I'll do it anyway :-)
Let's assume there are some contexts where doing a memory
allocation with a size of 0 is invalid while in some other contexts
it is valid. Wouldn't it make sense in that case to have two
functions that do memory allocation?
Of course su
Anthony Liguori writes:
> Markus Armbruster wrote:
>> Commit a7d27b53 made zero-sized allocations a fatal error, deviating
>> from ISO C's malloc() & friends. Revert that, but take care never to
>> return a null pointer, like malloc() & friends may do (it's
>> implementation defined), because th
Because Qemu currently requires a TCG target to exist and there are quite some
useful helpers here to lay the groundwork for out KVM target, let's create a
stub TCG emulation target for S390X CPUs.
This is required to make tcg happy. The emulation target itself won't work
though.
Signed-off-by: A
This patch adds information about who handles what when it comes to S390.
I'll gladly support anything that's related to the device emulation model and
S390 KVM parts.
Since this patchset doesn't implement S390 CPU emulation, I left that part
with a question mark. As soon as Uli's patchset gets co
In order to use the new S390x virtio bus we just introduced, we also
need a machine description that sets up the machine according to our
PV specification.
Let's add that machine description and be happy!
Signed-off-by: Alexander Graf
---
v4 -> v5
- disable early console
v5 -> v6:
- make
All "normal" system emulation targets in qemu I'm aware of display output
on either VGA or serial output.
Our S390x virtio machine doesn't have such kind of legacy hardware. So
instead we need to default to a virtio console.
I'm not particularly proud of this patch. It would be a lot better to
ha
On S390x we don't want to go through the hassle of emulating real existing
hardware, because we don't need to for running Linux.
So let's instead implement a machine that is 100% based on VirtIO which we
fortunately implement already.
This patch implements the bus that is the groundwork for such
Let's enable the basics for system emulation so we can run virtual machines
with KVM!
Signed-off-by: Alexander Graf
---
target-s390x/cpu.h| 153 -
target-s390x/exec.h |5 +
target-s390x/helper.c | 22 +
targ
KVM on S390x requires the virtual address space of the guest's RAM to be
within the first 256GB.
The general direction I'd like to see KVM on S390 move is that this requirement
is losened, but for now that's what we're stuck with.
So let's just hack up qemu_ram_alloc until KVM behaves nicely :-).
In order to debug funny kernel breakages it's always good to have a working
gdb stub around.
While Uli's patches don't include one one, I needed one that's at least good
enough for 'bt' and some variable examinations during early bootup.
So here it is - the absolute basics to get the qemu gdb stu
Qemu won't let us run a KVM target without having host TCG support. Well, for
now we don't have any so let's implement a fake target that only stubs out
everything.
I tried to keep the patch as close to Uli's source as possible, so whenever
he feels like it he can easily diff his version against t
S390x was one of the first platforms that received support for KVM back in the
day. Unfortunately until now there hasn't been a qemu implementation that would
enable users to actually run guests.
So let's include support for KVM S390x in qemu!
Signed-off-by: Alexander Graf
---
v5 -> v6:
- u
This patch makes configure aware of S390 hosts and guests. When not explicitly
defined using --target-list= no S390 targets will be built though.
Signed-off-by: Alexander Graf
---
configure | 25 ++---
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/configur
While S390x was one of the first targets that were supported by KVM it always
lacked qemu system emulation support.
In order to change that sad fact, I figured I'd just take on the task myself,
taking kuli (http://www.ibm.com/developerworks/linux/linux390/kuli.html),
Documentation/s390/kvm.txt and
From: Igor V. Kovalenko
- match global tte against any context
- show global tte in MMU dump
Signed-off-by: Igor V. Kovalenko
---
target-sparc/cpu.h | 18
target-sparc/helper.c| 18 +++-
target-sparc/op_helper.c | 53
52 matches
Mail list logo
