Anthony Liguori anth...@codemonkey.ws writes:
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
Avi Kivity a...@redhat.com writes:
A NEW(type) and ARRAY_NEW(type, count) marcros would improve type
safety and plug a dormant buffer overflow due to multiplication
overflow, yes. Even qemu_calloc() would be an improvement. But
having qemu_malloc() not fix the zero length array case which
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sat, 5 Dec 2009, Markus Armbruster wrote:
Anthony Liguori anth...@codemonkey.ws writes:
Markus Armbruster wrote:
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sat, 5 Dec 2009, Markus Armbruster wrote:
Anthony Liguori anth...@codemonkey.ws writes:
Markus Armbruster wrote:
Commit a7d27b53 made zero-sized allocations a fatal error,
On Sun, Dec 6, 2009 at 10:39 AM, malc av1...@comtv.ru wrote:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sat, 5 Dec 2009, Markus Armbruster wrote:
Anthony Liguori anth...@codemonkey.ws writes:
Markus Armbruster wrote:
Commit a7d27b53 made
On Sun, 6 Dec 2009, Blue Swirl wrote:
On Sun, Dec 6, 2009 at 10:39 AM, malc av1...@comtv.ru wrote:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
[..snip..]
$ gcc mall.c
$ ./a.out
ptr 0x46974060
$
Changing read count to 1:
$ ./a.out
ptr 0x41ce0070
a.out: read: Bad address
Thanks.
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
[..snip..]
read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
buffer when the size is zero.
[..snip..]
Yet under linux the address is checked even for zero case.
I don't know what a
On 12/06/2009 12:22 PM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents the implementor
from setting aside a range of addresses with 31st bit set as an
indicator of zero allocations, and then happily giving it to
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
[..snip..]
read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
buffer when the size is zero.
[..snip..]
Yet under linux the address is checked even for zero
On 12/06/2009 11:22 AM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents the implementor
from setting aside a range of addresses with 31st bit set as an
indicator of zero allocations, and then happily giving it to
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 12:22 PM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents the implementor
from setting aside a range of addresses with 31st bit set as an
indicator of zero
On Sat, Dec 05, 2009 at 08:07:13PM +, Blue Swirl wrote:
On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno aurel...@aurel32.net 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 aurel...@aurel32.net
wrote:
On Wed, Dec 02,
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
On Sun, 6 Dec 2009, Markus Armbruster wrote:
malc av1...@comtv.ru writes:
[..snip..]
read(fd, malloc(0), 0) is just fine, because read() doesn't touch the
buffer when the size is zero.
On Sun, 6 Dec 2009, Paolo Bonzini wrote:
On 12/06/2009 11:22 AM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents the implementor
from setting aside a range of addresses with 31st bit set as an
indicator of
On 12/06/2009 01:53 PM, malc wrote:
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 12:22 PM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents the implementor
from setting aside a range of addresses
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 01:53 PM, malc wrote:
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 12:22 PM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents
On 12/06/2009 02:11 PM, malc wrote:
The implementation needs to track which addresses it handed out, since it
is
required that malloc(0) != malloc(0) (unless both are NULL).
You haven't read carefully, i said range.
So? There will be tracking, it's the same as with
On Thu Dec 03, 2009 at 17:24:59 -0600, Anthony Liguori wrote:
+struct MultibootState {
+void *mb_buf; /* buffer holding kernel, cmdlines and mb_infos */
+uint32_t mb_buf_phys; /* address in target */
+int mb_buf_size; /* size of mb_buf in bytes */
+int
Move multiboot loading code into a separate files as suggested by Alex Graf.
Signed-off-by: Adam Lackorzynski a...@os.inf.tu-dresden.de
---
Makefile.target |2 +-
hw/multiboot.c | 326 +++
hw/multiboot.h | 12 ++
hw/pc.c |
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.
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 andreas.faer...@web.de
Cc: John Arbuckle programmingk...@gmail.com
---
cocoa.m |6 +++---
1 files changed, 3 insertions(+), 3
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.
On 06.12.2009, at 14:00, Andreas Faerber wrote:
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
On 12/06/2009 01:25 AM, Ian Molton wrote:
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?
Am 06.12.2009 um 07:28 schrieb malc:
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,
Hi Alex,
Am 06.12.2009 um 14:02 schrieb Alexander Graf:
On 06.12.2009, at 14:00, Andreas Faerber wrote:
Fix integer usage in the Cocoa backend: NSInteger is long on LP64.
Am 13.07.2009 um 22:37 schrieb G 3:
This patch adds the missing function prototype cocoa_keycode_to_qemu
to cocoa.m.
Signed-off-by: John Arbuckle programmingk...@gmail.com
---
cocoa.m |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cocoa.m b/cocoa.m
index
On 06.12.2009, at 14:23, Andreas Färber wrote:
Hi Alex,
Am 06.12.2009 um 14:02 schrieb Alexander Graf:
On 06.12.2009, at 14:00, Andreas Faerber wrote:
Fix integer usage in the Cocoa backend: NSInteger is long on LP64.
On 06.12.2009, at 14:00, Andreas Faerber wrote:
-int rectCount;
+NSInteger rectCount;
I know that this is endorsed by apple since 10.5 but NSInteger will break
compiling on Tiger and older. Int on the other hand is only throwing a warning
on Leopard if I'm not
Am 06.12.2009 um 14:41 schrieb Mike Kronenberg:
On 06.12.2009, at 14:00, Andreas Faerber wrote:
-int rectCount;
+NSInteger rectCount;
I know that this is endorsed by apple since 10.5 but NSInteger will
break compiling on Tiger and older.
You appear to be right
Ian Molton wrote:
Jamie Lokier wrote:
I'm a bit puzzled.
Why isn't virtio-rng getting entropy from /dev/random on the host?
/dev/random may not be available.
Understood on a non-Linux host.
Besides, not all entropy comes from /dev/random.
On a Linux host, why isn't rngd simply
KVM_GET_MSR_INDEX_LIST returns -E2BIG when the provided space is too
small for all MSRs. But this is precisely the error we trigger with the
initial request in order to obtain that size. Do not fail in that case.
This caused a subtle corruption of the guest state as MSR_STAR was not
properly
Sorry, this is of course a critical fix for all branches that have KVM
support.
Jan
Jan Kiszka wrote:
KVM_GET_MSR_INDEX_LIST returns -E2BIG when the provided space is too
small for all MSRs. But this is precisely the error we trigger with the
initial request in order to obtain that size. Do
Jan Kiszka wrote:
Avi Kivity wrote:
On 12/03/2009 09:23 PM, Jan Kiszka wrote:
Jan Kiszka wrote:
Problem 2
-
Setup: qemu head with vmstate fixes. kvm-kmod master, 64-bit host guest.
Effect: The migration target either locks up or reboots immediately.
I've nailed this down to
On 12/06/2009 04:51 PM, Jan Kiszka wrote:
KVM_GET_MSR_INDEX_LIST returns -E2BIG when the provided space is too
small for all MSRs. But this is precisely the error we trigger with the
initial request in order to obtain that size. Do not fail in that case.
This caused a subtle corruption of the
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.
v3:
-
Missing static for cocoa_keycode_to_qemu.
Missing const for character constant.
__LITTLE_ENDIAN__ is undefined on Big Endian host.
MAC_OS_X_VERSION_10_4 is undefined on v10.3 and earlier.
v3:
- Silence warnings reported from Mac OS X v10.3.9
Signed-off-by: Andreas Faerber andreas.faer...@web.de
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.
On Sun, Dec 6, 2009 at 11:59 AM, Aurelien Jarno aurel...@aurel32.net wrote:
On Sat, Dec 05, 2009 at 08:07:13PM +, Blue Swirl wrote:
On Sat, Dec 5, 2009 at 8:05 PM, Aurelien Jarno aurel...@aurel32.net wrote:
On Thu, Dec 03, 2009 at 10:03:18PM +0200, Blue Swirl wrote:
On Thu, Dec 3, 2009
Am 18.09.2009 um 18:18 schrieb G 3:
This patch eliminates all the warnings and errors that appear when
compiling cocoa.m on Mac OS 10.4 and under.
Signed-off-by: John Arbuckle programmingk...@gmail.com
---
cocoa.m | 25 -
1 files changed, 16 insertions(+), 9
On 12/06/2009 01:02 PM, malc wrote:
On Sun, 6 Dec 2009, Paolo Bonzini wrote:
On 12/06/2009 11:22 AM, malc wrote:
Here, i believe, you are inventing artificial restrictions on how
malloc behaves, i don't see anything that prevents the implementor
from setting aside a range of addresses with
On 12/06/2009 01:00 PM, malc wrote:
or anything else with said bit set will yield EFAULT. Consequently the
code you cited as a well behaving malloc(0) call site will bomb.
It is not well-behaving unless the definition of EFAULT is changed
consistently.
Paolo
Hello,
Am 12.11.2009 um 19:15 schrieb G 3:
The Priority menu controls how much cpu time qemu receives, and the
Machine menu has the Restart menu item for restarting the emulator.
Signed-off-by: John Arbuckle programmingk...@gmail.com
---
cocoa.m | 91
Jamie Lokier wrote:
Ian Molton wrote:
Jamie Lokier wrote:
I'm a bit puzzled.
Why isn't virtio-rng getting entropy from /dev/random on the host?
/dev/random may not be available.
Understood on a non-Linux host.
Or a linux host with a user with insufficient privs...
Besides, not all
Markus Armbruster wrote:
p = malloc(n * sizeof(struct foo);
if (n !p)
exit_no_mem();
for (i = 0; i n; i++)
compute_one(p, i);
With qemu_malloc(), the error handling moves into qemu_malloc():
p = qemu_malloc(n * sizeof(struct foo);
for (i = 0; i
Avi Kivity wrote:
On 12/06/2009 01:25 AM, Ian Molton wrote:
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
On 12/06/2009 06:58 PM, Ian Molton wrote:
Avi Kivity wrote:
On 12/06/2009 01:25 AM, Ian Molton wrote:
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
On 12/06/2009 06:52 PM, Ian Molton wrote:
Markus Armbruster wrote:
p = malloc(n * sizeof(struct foo);
if (n !p)
exit_no_mem();
for (i = 0; i n; i++)
compute_one(p, i);
With qemu_malloc(), the error handling moves into qemu_malloc():
p =
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 06:58 PM, Ian Molton wrote:
Avi Kivity wrote:
On 12/06/2009 01:25 AM, Ian Molton wrote:
Avi Kivity wrote:
It's not that it doesn't have a way to report failure, it's that it
doesn't fail.
On 12/06/2009 07:47 PM, malc wrote:
It will never fail on Linux. On other hosts it prevents a broken oom handler
from taking the guest down a death spiral.
It fails here all the time i'm sorry to say, i have overcommit disabled
(mostly because kpdf when doing a text search tends to
On 12/06/2009 07:45 PM, malc wrote:
And you lose the ability to fail gracefully...
We never had it. Suppose p is allocated in response to an SCSI register
write, and we allocate a scatter-gather list. What do you do if you OOM?
Uh, please do not generalize.
Sorry.
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 07:47 PM, malc wrote:
It will never fail on Linux. On other hosts it prevents a broken oom
handler
from taking the guest down a death spiral.
It fails here all the time i'm sorry to say, i have overcommit disabled
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 07:45 PM, malc wrote:
And you lose the ability to fail gracefully...
We never had it. Suppose p is allocated in response to an SCSI register
write, and we allocate a scatter-gather list. What do you do if
On 12/06/2009 08:09 PM, malc wrote:
Well, i don't have a swap...
~$ cat /proc/meminfo
MemTotal: 515708 kB
MemFree: 3932 kB
Buffers: 10120 kB
Cached: 365320 kB
SwapCached: 0 kB
Active: 238120 kB
Inactive: 222396 kB
SwapTotal: 0 kB
On 12/06/2009 08:12 PM, malc wrote:
Init is pretty easy to handle. I'm worried about runtime where you can't
report an error to the guest. Real hardware doesn't oom.
Here, i do agree, but mostly because most of the users of allocation
functions just themselves returned NULL or -1 or
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 08:09 PM, malc wrote:
Well, i don't have a swap...
~$ cat /proc/meminfo
MemTotal: 515708 kB
MemFree: 3932 kB
Buffers: 10120 kB
Cached: 365320 kB
SwapCached: 0 kB
Active:
Ian Molton wrote:
Read the beginning of the thread. Basically it's for arrays, malloc(n *
sizeof(x)).
well, make sure n is not 0. Its not that hard. I dont think I've *ever*
had a situation where I wanted to pass 0 to malloc.
I would like to remind everyone that sizeof(x) can be 0 too.
Avi Kivity wrote:
A NEW(type) and ARRAY_NEW(type, count) marcros would improve type safety
and plug a dormant buffer overflow due to multiplication overflow, yes.
Even qemu_calloc() would be an improvement.
In my code I regularly use type_alloc(type) and type_free(type, ptr),
giving type
On Sun, 6 Dec 2009, Avi Kivity wrote:
On 12/06/2009 08:12 PM, malc wrote:
Init is pretty easy to handle. I'm worried about runtime where you can't
report an error to the guest. Real hardware doesn't oom.
Here, i do agree, but mostly because most of the users of allocation
Avi Kivity wrote:
Init is pretty easy to handle. I'm worried about runtime where you
can't report an error to the guest. Real hardware doesn't oom.
In the case of the socket reconnect code I posted recently, if the
allocation failed, it would give up trying to reconnect and inform the
user
malc wrote:
Well, i don't have a swap...
Indeed, nor do I (machine has an NFS root. swap on NFS is... not good.)
The QEMU team is pleased to announce the availability of the 0.12.0-rc1
release. This is the first release candidate for the 0.12.0 release.
This release is not intended for production use.
Testing release candidates is a great way to contribute to QEMU and
improve the quality of the 0.12.0
On Wed, Sep 30, 2009 at 08:02:08AM -0500, Anthony Liguori wrote:
Hi Isaku,
Isaku Yamahata wrote:
Is there any documentation available about where those git repo are and
how to compile?
Fortunately I was able to find the repo
in git.qemu.org by digging out the ML archive.
However there
Ian Molton wrote:
Besides, not all entropy comes from /dev/random.
On a Linux host, why isn't rngd simply injecting it's entropy into
/dev/random where it would be more convenient to access? (No need for
socket reconnection code, for example).
Who knows? lack of privs, an admin who
Ian Molton wrote:
Avi Kivity wrote:
Init is pretty easy to handle. I'm worried about runtime where you
can't report an error to the guest. Real hardware doesn't oom.
In the case of the socket reconnect code I posted recently, if the
allocation failed, it would give up trying to
Isaku Yamahata wrote:
On Wed, Sep 30, 2009 at 08:02:08AM -0500, Anthony Liguori wrote:
Hi Isaku,
Isaku Yamahata wrote:
Is there any documentation available about where those git repo are and
how to compile?
Fortunately I was able to find the repo
in git.qemu.org by digging out the
On Sun, Dec 06, 2009 at 08:52:11PM -0600, Anthony Liguori wrote:
Isaku Yamahata wrote:
On Wed, Sep 30, 2009 at 08:02:08AM -0500, Anthony Liguori wrote:
Hi Isaku,
Isaku Yamahata wrote:
Is there any documentation available about where those git repo are
and how to compile?
67 matches
Mail list logo
