Anthony Liguori 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 have
Avi Kivity 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 we know
> we
On Sun, 6 Dec 2009, Markus Armbruster wrote:
> 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() & friend
malc writes:
> On Sun, 6 Dec 2009, Markus Armbruster wrote:
>
>> 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
>> >> >> fro
On Sun, Dec 6, 2009 at 10:39 AM, malc wrote:
> On Sun, 6 Dec 2009, Markus Armbruster wrote:
>
>> malc writes:
>>
>> > On Sat, 5 Dec 2009, Markus Armbruster wrote:
>> >
>> >> Anthony Liguori writes:
>> >>
>> >> > Markus Armbruster wrote:
>> >> >> Commit a7d27b53 made zero-sized allocations a fata
On Sun, 6 Dec 2009, Blue Swirl wrote:
> On Sun, Dec 6, 2009 at 10:39 AM, malc 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 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 "valid poi
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 t
malc writes:
> On Sun, 6 Dec 2009, Markus Armbruster wrote:
>
>> malc 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.
Any
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 t
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
On Sat, Dec 05, 2009 at 08:07:13PM +, Blue Swirl wrote:
> 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, Ant
On Sun, 6 Dec 2009, Markus Armbruster wrote:
> malc writes:
>
> > On Sun, 6 Dec 2009, Markus Armbruster wrote:
> >
> >> malc 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
> > indica
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 w
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 any
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 OpenBSD
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 m
Move multiboot loading code into a separate files as suggested by Alex Graf.
Signed-off-by: Adam Lackorzynski
---
Makefile.target |2 +-
hw/multiboot.c | 326 +++
hw/multiboot.h | 12 ++
hw/pc.c | 300 +---
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
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
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
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, s
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.
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSVie
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
---
cocoa.m |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/cocoa.m b/cocoa.m
index 3bf1a87..1e5fbe8 100644
--- a/cocoa.
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.
>>>
>>> http://developer.apple.com/mac/library/docume
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 mistak
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 th
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
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 saved
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.
>>
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 gu
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
Cc: John Arbuckle
Cc:
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
On Sun, Dec 6, 2009 at 11:59 AM, Aurelien Jarno wrote:
> On Sat, Dec 05, 2009 at 08:07:13PM +, Blue Swirl wrote:
>> 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
>>
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
---
cocoa.m | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/cocoa.
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 31s
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
---
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...
>> B
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
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 all
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 don't
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 = qemu_mall
On Sun, 6 Dec 2009, Avi Kivity wrote:
> 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);
> > >
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, i
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 over
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
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
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
S
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 wh
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
> >
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
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 s
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
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 r
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.
>> Ho
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, a
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 t
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 ML
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
68 matches
Mail list logo
