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
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
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
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
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
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
malc wrote:
> Well, i don't have a swap...
Indeed, nor do I (machine has an NFS root. swap on NFS is... not good.)
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
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:
> 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
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
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
> >
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 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 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 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 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 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 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 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 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 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
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
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
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
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 +
+
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
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
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 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
>>
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.
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:
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:
-
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
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.
>>
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
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
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
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
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
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
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.
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 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
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?
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
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
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 +---
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
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 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 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, 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 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 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, 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 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
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 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
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 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, 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
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, 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
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
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
68 matches
Mail list logo
